В околотему про касты. Как валиднее всего написать функцию, которая

не скомпилируется если я вдруг попробую собрать код там, где usize != u64?

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

Можно вызвать panic в const

#[cfg(target_pointer_width = "64")] мб

Можно засунуть пару функций конверсий туда-сюда под cfg(target_pointer_width = "64") На CHERI свалится, наверное, но полезность портирования под неё скорее сомнительна (кроме специфичных условий)

А чем u32 плох? Все равно столько памяти не выделишь

Я интерпретатор пишу, там переменные могут и индексами быть, и числами, взял для простоты u64, но кастить приходится всё равно.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e986c3219f49c5455f57bbc0d4e9f4aa Норм, выпилил все явные касты в числа из кода, теперь поспокойнее (as u32 правда не трогал, но пока лень просто). И исходный тип незаметно не поменяется, и не страшно что откуда ни возьмись отрицательное не вылезет. // убрал cfg() от checked_positive_isize_to_usize()

Не слишком много вариантов по сути одинаковых функций? Может дженерики?

С дженериками суть пропадёт.

TryFrom существует

А bounds? Если создать свой трейт. Или функция cast<T, U>

Просто таким кодом ты сам замучаешься. Мало того что используешь cfg, так у тебя и названия функций разные!!! Так делать не надо. Cfg используют когда названия функций одинаковые, просто меняется содержимое в зависимости от архитектуры

Кастую редко, не замучаюсь. cfg() я тут написал просто чтобы развалить сборку если касты которые я ожидаю что будут ну совсем noop-операцией вдруг могут начать терять данные, если решил скомпилировать под калькулятор.

Хм. Но тебе все равно нужна функция заглушка для других архитектур. А то даже не скомпилируется. Ну то есть под твою конкретную конечно скомпилируется, а под другие нет

Мне и не нужно чтобы компилировалось)