A
эх, а в были бы завтипы...)))
Не обязательно. Хватило бы операторов на уровне типов и типов сумм.
Size: a a a
2020 April 02
AZ
Не обязательно. Хватило бы операторов на уровне типов и типов сумм.
ну это и есть завтипы, только огрызочные немного
A
ну это и есть завтипы, только огрызочные немного
Нет. Завтипы это когда операторы на уровне типов зависят не только от типов, но и значений.
AZ
ну, ок, уговорил
AZ
все равно в мейнстрим языках этог онет
A
Смотря что считать мейнистримом. Скала - мейнстрим?
AZ
Смотря что считать мейнистримом. Скала - мейнстрим?
не уверен. На грани
AZ
вряд ли скала в топ 20 входит
AZ
а я бы мейнстрим так определял
p
Нет. Завтипы это когда операторы на уровне типов зависят не только от типов, но и значений.
завтипы это когда тип значения зависит от других значений, откуда ты выкопал операторы непонятно
A
завтипы это когда тип значения зависит от других значений, откуда ты выкопал операторы непонятно
Окей. Один фиг завтипы и type level operators это разные вещи.
DS
Нет. Завтипы это когда операторы на уровне типов зависят не только от типов, но и значений.
Там всё хитрее.
В целом считается, что для зав типов достаточно, чтобы были выразимы зависимая функция и зависимая пара, но для того, чтобы этим было удобно пользоваться нужно куча всего ещё.
В целом считается, что для зав типов достаточно, чтобы были выразимы зависимая функция и зависимая пара, но для того, чтобы этим было удобно пользоваться нужно куча всего ещё.
A
Я про завтипы мало что знаю, на самом деле.
p
Смотрел и использовал. Все равно не понял, как делать удобно.
Вот пример задачи: пусть у нас есть 2 функции, одна может вернуть ошибк IoError, NotFound, ParseError, втора NotFound, LogicError.
Нам нужно эти две функции вызвать из третьей, прокинуть ошибку вверх а наверху уже обработать только NotFound прокинув остальные дальше.
В anyhow удобно прокидывать ошибки, но по сигнатуре вообще не видно какие там ошибки идут и неудобно конкретную обрабаывать.
Вот пример задачи: пусть у нас есть 2 функции, одна может вернуть ошибк IoError, NotFound, ParseError, втора NotFound, LogicError.
Нам нужно эти две функции вызвать из третьей, прокинуть ошибку вверх а наверху уже обработать только NotFound прокинув остальные дальше.
В anyhow удобно прокидывать ошибки, но по сигнатуре вообще не видно какие там ошибки идут и неудобно конкретную обрабаывать.
делаешь перечисление всех ошибок, дерайвишь From, и на ошибках перед возвратом делаешь .map_err(Into::into)
A
делаешь перечисление всех ошибок, дерайвишь From, и на ошибках перед возвратом делаешь .map_err(Into::into)
Если у функция один может возвращать MyFunc1Enum::IOError, в функции 3 у меня есть MyFunc3Enum::IOError, оба на самом деле просто оберки над io::Error. Деравинг сделает мне корректный проброс ошибки в данном случае?
p
Если у функция один может возвращать MyFunc1Enum::IOError, в функции 3 у меня есть MyFunc3Enum::IOError, оба на самом деле просто оберки над io::Error. Деравинг сделает мне корректный проброс ошибки в данном случае?
ну тогда вручную реализовать Into<MyEnumError> for MyFunc3Enum
A
ну тогда вручную реализовать Into<MyEnumError> for MyFunc3Enum
Собственно это я и имел в виду, что нет удобного варианта. Т.е. когда у нас много функций, с разными типами ошибок, которые надо прокинуть вверх и залогировать получается много писанины.
p
ну тут никак не сделаешь удобно
p
а нет, сделаешь. С завтипами)
A
Какие нибудь анонимные енамы, чтобы можно было писать ErrorOne | ErrorTwo | ErrorThree