Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, _NN_, Вы писали:

_>>>Компилятор должен помогать программисту в его работе быть скучным и предсказуемым, а не удивлять его сюрпризами. Короче шланг гавно.
_NN>>Есть вариант делать предсказуемое поведение и жаловаться на неоптимальносгенерируемый код.
_NN>>Каков ваш выбор ?
_>Совершенно очевидно, что выбор должен быть явным. Если вы хотите контролировать переполнение явно это указывайте компилятору.
_>

_>checked int a; // проверяйте of флаг и т.п.
_>module int b; // обычная модульная арифметика, в ней нет переполнений
_>saturated int c; // арифметика с насыщением, не коммутативна и т.п. приколы
_>

Ну это не проблема checked<int> , modulo<int>.
И будет вам предсказуемость.
Но что-то я не встречал такое в промышленном коде.
Может людям не особо она и нужна

_NN>>Например, у нас беззнаковые числа имеют предсказуемость при переполнении и в итоге получаем лишние инструкции процессора от которых не избавиться.
_NN>>Пример: https://gcc.godbolt.org/z/11rWEjzdv
_>Если вы знаете рабочие диапазоны то переполнений не будет.
Не будет до поры до времени.
Если в коде нет явного контроля, то переполнение может случиться в самый неподходящий момент.

_>А если нужна длинная арифметика надо bignum тип иметь. Что бы он мог как строки динамически расширяться пр

_NN>>Есть библиотека jtckdint, а начиная с C++26 будет Checked integer arithmetic в стандартной библиотеке.
_NN>>Уже пользуетесь и пишете скучный и предсказуемый код ?
_>Да в 146% случаев нужен скучный, предсказуемый код, который выполняет именно то что его попросили.

В плюсах решается введением обёрток и запрет на использования отличных от них типов.
Вполне решаемо статическим анализом.
Осталось только привнести в массы и убедить, что нужно писать именно так, а не просто int sum(int a, int b).

Я к тому, что хорошо бы конечно, чтобы было по другому, но мы имеем то, что имеем, а поменять семантику не так легко. Даже если починить это сломает какой-нибудь сценарий