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

К>В конкретном месте приводи к int и работай с ним, если ты прямо вот уверен, что никогда не выбежишь из разрядной сетки или не схватишь знаковый разряд как обычный.

Понимаешь, в чём проблема. Если я забуду привести к инту при сложении u8+u8, то я получу падающий код. И компилятор ничего мне на это не скажет. То есть эти ограниченные Strong Types сами порождают грабли, хотя по задумке якобы должны от них защищать. И что самое хреновое — правильный код выглядит грязнее и хуже, чем неправильный но компилирующийся.

К>Когда в большом плюсовом проекте включили варнинг компилятора о числовых преобразованиях, — ух, сколько аннотаций пришлось расставить, ты бы знал.

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

К>Да, фигня какая, вдвое больше места и вчетверо медленнее вычисления.

Отбрось лишние биты (старшие или младшие — в зависимости от задачи) и будет быстрое время.

К>Аха, то есть, координаты для промежуточных вычислений (а не только перед финальным округлением) у нас уже полуцелые. Кто тут говорил, что int хватит?

Очевидно, что пример с шахматной доской это не тот же пример, что с векторами-точками.

К>Почему точка ровно посередине отрезка AB имеет физический смысл, а шестая по счёту точка на гребёнке из десяти засечек — не имеет физический смысл?

Потому что мне нужен корректный код. Если я опечатался и написал a+(b-a)*0.6, то мне от этого ничуть не легче, чем если бы я написал (a+b)*0.6. Результат в обоих случаях неверен.
Можно поспекулировать на тему, что во втором случае я замечу, что поведение системы меняется в зависимости от расстояния до нуля и поэтому быстрее найду причину бага, но это спекуляции, потому что в разных случаях может быть по-разному.

К>Я вот тоже думал "нафига ввели точку, есть же вектор" — до того момента, как не полез в "промышленную" геометрию.
К>Так что все эти вещи — выстраданные.

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

И раз уж мы вспомнили про прошивки ядерных реакторов, то давай вернёмся к моему примеру про сложение u8+u8, которое компилятор не отловит. Ну и тогда уж, чтоб намёк про "надёжность" ограниченных типов был понятнее — давай заменим ядерный реактор на ракету Ариан-5