ΑZ
ну для этого и есть рфц. Предложи свой вариант - узнаешь есть ли у других такие проблемы или нет.
Size: a a a
2021 June 17
ΑZ
у меня вот нет, я поставлю минус
Z
так речь не только про ()
B
да юзлесс это, лишний сахар всегда усложняет
AM
давайте на этом и закончим)
TK
Разделение ответственности, дабы не писать одну большую лапшу при конверсиях, способных сфейлиться, и нуждающихся в длинных проверках по типу ассертов, но без паник
B
еще решите как быть с Result<Result<Result<Result....
B
если вы не только про ()
ΑZ
можно просто вместо
foo?
bar?
Ok(())
написать
foo?
bar
и не писать ужасных буков
foo?
bar?
Ok(())
написать
foo?
bar
и не писать ужасных буков
B
в свифте опционал через ?, типа T? и любое значение типа T неявно конвертируется в него. Иногда это удобно а иногда с этим проблемы, особенно когда T??????
Р
у меня редко когда бывает
Result<Result<T>>, обычно все приводится к Result<T> с помощью and_then или по другомуTK
Нельзя, в основной функции конверсии не требуется возвращать юнит, во вспомогательных же как раз и надо
AM
может тут комбинаторы просто нужны? все равно звучит сомнительно
TK
Комбинаторы мб
TK
Проблема всё равно та же будет и в комбинаторах, имхо
TK
"Проблема"
TK
Я против сахара, зачем Жуковский со мной спорит - хз, просто вариант решения предложил
ΑZ
? это и есть сахар для упрощения комбинаторов. Обратно на них это даунгрейд
TK
Даже так всего один Ok(()) в проекте, так шо мне тоже безразлично
B
лучше бы обсудили почему так нельзя