Rust 1.45.0: стабилизация функциональных процедурных макросов, исправление дефектов преобразования

[@netch80]

> as будет выполнять «насыщающее приведение» (saturating cast),

Не очень видно логики. В случае целочисленных действий, например, есть явные операции типа checked_add, overflowed_add, а есть просто "+", которое одно из них в зависимости от режима компиляции. Почему не точно так же с конверсией из плавающего?

Переводить poison value как «испорчено» — странная манера… точно нет варианта лучше?

[@kovserg]

Хреново когда нет исключений. Но можно же было просто остановить исполнение с помощью std::panic

[@netch80]

Ну паники это и есть аналог исключений для Rust (разница для данного вопроса неважна), и распаковка, если checked_add выдал None, даст панику, а можно и явно проверить. Тут ровно такое же можно было бы провернуть.

[@freecoder_xx]

Если вам нужно такое поведение — используйте TryFrom.

[@netch80]

Спасибо, я в курсе, и с ходу могу придумать ещё пару методов получить нужный результат. Но обидно за неконсистентность.

[@humbug]

Согласен. https://github.com/rust-lang/rust/issues/74499

[@Kroid]

Мне кажется, было бы лучше вообще запретить любые преобразования чисел с большим разрядом в числа с меньшим. Нужно 8 бит — значит, изначально возьми именно 8 бит, вместо того чтобы парсить 32 бита с риском получить на выходе какую-то фигню.

[@humbug]

Для целых чисел есть TryFrom/TryInto. Можно проверить, поместится ли число в целевой тип.
Запрет на любые преобразования чисел с большим разрядом в младшие — драконовы меры.

[@defuz]

Последние годы чуть ли не самое интересное в обновлениях Rust, это «скучный» список в конце статьи с оглавлением «В Rust 1.*.0 были стабилизированы следующие функции».

Каждый раз прокликиваю этот список в попытках вспомнить, не стабилизировали ли они что-то такое, из-за чего когда-то руки чесались перейти на nightly, но вместо этого пришлось городить костыли.

Мне кажется, что команде Rust пишущей анонсы стоит уделять большие внимание новым стабилизированным возможностям стандартной библиотеки, потому что для большинства разработчиков Rust – это новые возможности, а ребята как-будто до сих пор живут в предубеждении что каждый разработчик Rust хотя бы раз в жизни забутстрепил и собрал руками компилятор и знает наизусть весь список 439 еще не стабилизированых возможностей раста.

Тот же BTreeMap::remove_entry как минимум мне несколько раз нужен был точно.

[@pfemidi]

А версию 1.45.2, вышедшую почти неделю назад, 3 августа, так и не анонсировали.