Forward from: Pavlo Myroniuk
трошки розкрию свою відповідь на це
в чому перевага писати через into/try_into або from/try_from (в контексті числових типів):
* ми явно перетворюємо один тип чисел на інший. якщо буде помилка, то try_into/try_from це захендлить. ти не отримаєш неочікуваних значень
* якщо в тебе буде навіть код по типу usize::try_from(/* some value */).unwrap(), то це вже краще замість as, оскільки варіант із .unwrap простіше дебажити. воно відразу впаде на unwrap і буде видно де баг
* такі конвертації компілятором дуже добре оптимізовуються. ось приклад як кастинг u32 в usize через usize::try_from(n).unwrap() перетворюється в одну mov інструкцію: https://gcc.godbolt.org/z/Y4WjWTqh1
* якщо в тебе десь в коді змінився тип чисел, то із into/try_into ти відразу це побачиш, бо компілятор покаже. із as ти цього можеш не помітити. і це знову ж таки стає небезпечним місцем
* якщо лінь писати усі ці виклики функцій, то напиши собі мінімальний декларативний макрос. у нас є такий)
в чому перевага писати через into/try_into або from/try_from (в контексті числових типів):
* ми явно перетворюємо один тип чисел на інший. якщо буде помилка, то try_into/try_from це захендлить. ти не отримаєш неочікуваних значень
* якщо в тебе буде навіть код по типу usize::try_from(/* some value */).unwrap(), то це вже краще замість as, оскільки варіант із .unwrap простіше дебажити. воно відразу впаде на unwrap і буде видно де баг
* такі конвертації компілятором дуже добре оптимізовуються. ось приклад як кастинг u32 в usize через usize::try_from(n).unwrap() перетворюється в одну mov інструкцію: https://gcc.godbolt.org/z/Y4WjWTqh1
* якщо в тебе десь в коді змінився тип чисел, то із into/try_into ти відразу це побачиш, бо компілятор покаже. із as ти цього можеш не помітити. і це знову ж таки стає небезпечним місцем
* якщо лінь писати усі ці виклики функцій, то напиши собі мінімальний декларативний макрос. у нас є такий)