это зависит от взвешивающего. мне в корзине нужно среднее образование без пропаганды насилия, милитаризма и этатизма. знаете где его купить в этой стране?
Хм. Путь зерна подходит? (Disclaimer: лично ни разу там не был)
И не понял пока преимущества Result<res, err> над гошным res, err… ну кроме сахара в виде foo()?
Преимущество как раз понятное: при помощи Result<T, E> можно вернуть или ответ, или ошибку, поэтому воспользоваться ответом, проигнорировав ошибку, в принципе невозможно. Ну и, в отличие от Go, не возникает вопроса, что делать, если функция вернула nil, nil.
Чтобы написать тест (или сгенерировать автоматом как в QuickCheck, не важно) вам нужно знать какое-то св-во, которому должна удовлетворять ваша ф-я. Но если вы это св-во для тестов задали — значит, вы его не забыли. Значит, вы его учли в коде. Если же вы его забыли — то тест этой ошибки не поймает, т.к. не будет знать, что ему ловить.
3. Запомнить 10500 комбинация типа Shift+alt+T в современной среде разработки нереально. Потому что есть стандартные комбинации типа Ctrl+O, Ctrl+P, Ctrl+X/Z/C, а остальное назначается (упихивается) по принципу как получится.
а далее — ещё надо прогарантировать порядок вызова деструкторов. что само по себе тоже не тривиальная задача
А что там нетривиального? При выходе из функции деструкторы будут вызваны в порядке, противоположном тому, в котором объекты создавались. Ничего специально для этого делать не надо, только код в деструкторе прописать ровно один раз на всё приложение.
В Python, например, никакого разворачивания стека не происходит, поэтому исключения стоят столько же, сколько вызовы − пренебрежимо мало в большинстве ситуаций.
"Пренебрежимо мало" в контексте Python надо читать, как "также дорого, как и всё остальное в Python".
Но это всё-таки несколько другое дело, чем просто «написан на другом языке». Ни на каком языке не делают написание «с нуля», т.е. без обвязки и библиотек на других языках.
Хм. Путь зерна подходит? (Disclaimer: лично ни разу там не был)
Преимущество как раз понятное: при помощи
Result<T, E>можно вернуть или ответ, или ошибку, поэтому воспользоваться ответом, проигнорировав ошибку, в принципе невозможно. Ну и, в отличие от Go, не возникает вопроса, что делать, если функция вернулаnil, nil.У меня пара вопросов к вашему коду:
1. Почему вы везде в коде пишете
вместо более простого, понятного и производительного
?
2. Почему вы используете для параметров отдельных тел список вместо класса с именованными полями?
Ну да, сарай ill-typed.
А можете дополнить спецификацию? Потому что сейчас имеющейся информации недостаточно, чтобы записать логику.
В таких случаях может помочь QuickSpec
Уважаемый gBear, хочу напомнить, что статически типизированные ЯП не сводятся к C++, Java и C#.
Я бы не сказал, что копирование на
y(потому что(y)ank) — достаточно интуитивно.Ну...
Странно, я думал, через разбор сумм-типа это выглядит более красиво.
Тут возникает вопрос, насколько подробно нужно эти аннотации проверять: поверхностные проверки могут привести к неожиданному/нежелательному поведению, а полные проверки типов в рантайме могут на порядок-два замедлить исполнение программ.
А что там нетривиального? При выходе из функции деструкторы будут вызваны в порядке, противоположном тому, в котором объекты создавались. Ничего специально для этого делать не надо, только код в деструкторе прописать ровно один раз на всё приложение.
"Пренебрежимо мало" в контексте Python надо читать, как "также дорого, как и всё остальное в Python".
Можно переписать на языке с RAII (да хоть том же C++) и будет ещё проще.
Это когда запускаешь код с
-fdefer-type-errorsА тут точно двойной референс нужен?
Пилите статью, я думаю, Хабр оценит.
Да ну?
То есть мы тратим время на проверку типов и до написания программы, и во время её исполнения? Прям win-win какой-то.