История изменений
Исправление hateyoufeel, (текущая версия) :
А что с ним не так?
То, что между разными типами может быть гораздо больше одного способа преобразования. Например, между целочисленными и IEEE754. Пойди угадай, что там: floor, trunc или round? Или, например, преобразование из 754 в Bool. Как оно с NaN будет работать? А хз. Такие штуки должны быть максимально явными, иначе говна не разгребёшь.
И если на этапе написания кода об этом можно ещё задуматься и расставить типы максимально аккуратно, то через пару лет и десяток разработчиков изменений будет достаточно, чтобы говно где-то точно вылезло.
Ещё вездесущий .unwrap(), на использование которого библиотека просто толкает и пинает
Каким образом?
Отсутствием более удобных средств работы с ошибками кроме Result<>. В условиях, когда нет нормальных исключений, получается то что получается. У меня тут есть пара софтин на Rust, которые регулярно падают, потому что внутри какой-то библиотеки (даже не самой софтины!) сработал panic!() при ошибке в .unwrap(). Представь, как если бы каждая вторая сишная либа в случае, если не смогла что-то нормально обработать, дёргала abort(). Вот это из той же серии.
А вообще, возьми как-нибудь среднюю прогу на Rust и просто посмотри сколько раз там unwrap() дёргается. Каждый этот unwrap() – это потенциальный panic!() в случае, если инварианты изменятся и говнокодер забудет добавить проверку (а он забудет!).
Исправление hateyoufeel, :
А что с ним не так?
То, что между разными типами может быть гораздо больше одного способа преобразования. Например, между целочисленными и IEEE754. Пойди угадай, что там: floor или trunc? Или, например, преобразование из 754 в Bool. Как оно с NaN будет работать? А хз. Такие штуки должны быть максимально явными, иначе говна не разгребёшь.
И если на этапе написания кода об этом можно ещё задуматься и расставить типы максимально аккуратно, то через пару лет и десяток разработчиков изменений будет достаточно, чтобы говно где-то точно вылезло.
Ещё вездесущий .unwrap(), на использование которого библиотека просто толкает и пинает
Каким образом?
Отсутствием более удобных средств работы с ошибками кроме Result<>. В условиях, когда нет нормальных исключений, получается то что получается. У меня тут есть пара софтин на Rust, которые регулярно падают, потому что внутри какой-то библиотеки (даже не самой софтины!) сработал panic!() при ошибке в .unwrap(). Представь, как если бы каждая вторая сишная либа в случае, если не смогла что-то нормально обработать, дёргала abort(). Вот это из той же серии.
А вообще, возьми как-нибудь среднюю прогу на Rust и просто посмотри сколько раз там unwrap() дёргается. Каждый этот unwrap() – это потенциальный panic!() в случае, если инварианты изменятся и говнокодер забудет добавить проверку (а он забудет!).
Исходная версия hateyoufeel, :
А что с ним не так?
То, что между разными типами может быть гораздо больше одного способа преобразования. Например, между целочисленными и IEEE754. Пойди угадай, что там: floor или trunc? Или, например, преобразование из 754 в Bool. Как оно с NaN будет работать? А хз. Такие штуки должны быть максимально явными, иначе говна не разгребёшь.
И если на этапе написания кода об этом можно ещё задуматься и расставить типы максимально аккуратно, то через пару лет и десяток разработчиков изменений будет достаточно, чтобы говно где-то точно вылезло.
Ещё вездесущий .unwrap(), на использование которого библиотека просто толкает и пинает
Каким образом?
Отсутствием более удобных средств работы с ошибками кроме Result<>. В условиях, когда нет нормальных исключений, получается то что получается. У меня тут есть пара софтин на Rust, которые регулярно падают, потому что внутри какой-то библиотеки (даже не самой софтины!) сработал panic!() при ошибке в .unwrap(). Представь, как если бы каждая вторая сишная либа в случае, если не смогла что-то нормально обработать, дёргала abort(). Вот это из той же серии.