Такая себе корректность

Программа может работать совершенно правильно.
Просто в ней есть мертвый баганый код.
Да, качество кода там неоч, но это не дело компилятора требовать качественный код.

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

Компилятор же не компилирует программу, если там есть невызываемая функция, внутри которой типы не чекаются

Просто мёртвая баганая функция, по факту

Да.
Типы должны сходиться.
А вот бесконечная рекурсия, переполняющая стек, языком раст разрешается.
Если перестанешь - нарушишь обратную совместимость.
Но вот эта вот вечная рекурсия это самый базовый пример.
Может, например, вызываемая функция час в релизной сборке и месяц в дебажной работает.
Как ты отличишь ее от loop {}?

Обратная совместимость для конст функций? Там так давно завезли вызов других функций, что уже есть что ломать?

С тех пор как завезли - совместимость должна быть.
Но в любом случае, вторая часть моего поста более интересна чем обсасывание обратной совместимости. Разверну ее:
если ты попытался вычислить какую-то функцию с лимитом в N шагов, у тебя есть три варианта.
1) Произошла паника/UB/etc. В общем-то, мы можем в такой ситуации плевать на обратную совместимость, давать ошибку компиляции и жить.
2) Функция успешно вычислилась. Прекрасно, подставляем эту константу куда надо и радуемся.
3) Функция до сих пор не завершилась. Если мы пишем обычный оптимизатор, то все ясно - просто забрасываем эти попытки соптимизировать это выражение.
Но в этот момент мы как раз теряем гарантию обязательности оптимизации константых функций, потому что какие-то совершенно прекрасные, корректные во всех смыслах функции мы не будет вычислять при компиляции.

Ты думаешь, что в децималовском конструкторе где-то есть бесконечная рекурсия, чтобы он не оптимизировался?

https://docs.rs/rust_decimal/1.7.0/src/rust_decimal/decimal.rs.html#149
Конкретно с decimal лично я не вижу, что могло бы помешать заинлайнить и вычислисть Decimal::new.
Либо я что-то прям в упор не вижу, либо LLVM протупила. Если так, то надо просто чинить LLVM.
Тема с константыми функциями совершенно перпендикулярна оптимизации.

Ну, хотя бы потому, что компилятору/оптимизатору не составит труда самому это const-ы везде где можно распихать. Наверняка он что-то такое и делает.

Супер, мы пришли к соглашению

Именно.

Кто нибудь работал с sse интринсиками в Rust? Как извлечь первый элемент из __m128d? Например


 let valf64: f64 = _mm_round_pd(_mm_set_pd1(x), _MM_FROUND_RINT);

Но _mm_round_pd возврящает  __m128d

_mm_round_pd(…).0 не работает так как элементы приватные
_mm_extract_pd - отсутствует =)

В общем, сделал пока так. Но это очень тупо

#[repr(C)]
#[repr(align(16))]
struct F64x2(f64, f64);

// workaround since stdsimd lacks _mm_extract_pd support
let mut out = F64x2(0_f64, 0_f64);
unsafe {
 _mm_store_pd(
   &mut out.0,
   _mm_round_pd(_mm_set_pd1(x), _MM_FROUND_RINT)
 )
};

А packed_simd твой кейс не покрывает?

Мне не нужны портативные интринсики с фолбеком, кроме того stdsimd это core и должно все поддерживать. По крайней мере для x86, x86_64. Эти архитектуры там уже не экспериментальные в отдичии от того же aarch64

А все из-за чего? Из-за того, что внимание у Rust отсутствует rint и nearbyint =)

К слову, rint или «банковское» округление (Round half to even) или стохастическое округление или гауссиановское округление - это обычное округление в том же Python)

Пистон не системный, он себе может что угодно позволить делать обычным.