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

SP> Но С++ рассчитан больше на людей, которые программируют под чайник или мусорное ведро.
Очень спорное утверждение. Я не знаю ни одного С++ программиста, программирующего под чайник или мусорное ведро, а знакомых плюсовиков у меня много. Но даже если бы и да, то это ни на что не влияет, см. ниже. Впрочем, боль людей, пишущих для чайников, я действительно могу не понимать в силу отсутствия такого опыта.

SP>Давайте посмотрим такой код:
<cut>
Давайте.

SP>здесь по вашей логике надо истошно кричать и материться: забыли default или return. Но с точки зрения программиста, у него не может прийти код 3.
Да, нужно истошно кричать и материться. Компилятор не должен думать, что там за логика у программиста. Программист у себя в голове держит мысль "мамой клянусь, не может быть (flag & 3) == 3". А вот если этот флаг прилетит из поломанного пакета или из файла, записанного несовместимой версией, или ещё откуда, или предыдущий парсинг сломан, и в месте, где мы ожидаем флаг, лежит что-то такое, у чего младшие биты 0b11, то окажется, что мамой клялись напрасно.

Более того, если таки провал в ветку без return не случится, то и invalid instruction не будет, т.к. мы до ud2 не дойдём. А если дошли, то программист имел в голове неверные допущения.

Если программист "зуб даёт", то у него в современном компиляторе (а мы ведь на них жалуемся) есть масса способов выразить эту мысль: assert, [assume]], std::unreachable, да хоть abort() позови в ветке default, можно хоть return Type::Unknown, мы же всё равно в эту ветку не попадём, правда?

SP>Может у него раньше стоит проверка и сразу делается вывод об ошибке.
Может. А может, и нет, компилятору об этом откуда знать?

SP> Зачем ему явно обрабатывать невозможный сценарий?
Затем, чтобы показать компилятору, что мы знаем, что делаем. std::unreachable убирает предупреждение и более на генерацию кода не влияет.

SP> Тем более что в результате добавления return мы получим вместо 2-х инструкций 4. А функцию с 4 инструкциями компилятор может уже не захотеть инлайнить, например. А если даже захочет, то это уже рост кода на n*2. Так зёрнышко по зёрнышку и мы не влезем в память нашего чайника.
Нет, не получим.см. здесь, например. Добавление std::unrechable() убирает предупреждение и никаким иным образом на выхлоп не влияет. Ну или приведите пример, где получим, не гипотетически, а на практике, у меня не получилось, может плохо старался.
А, нет, влияет: как раз-таки при вставке std::unrechable компилятор перестаёт генерировать ud2, т.к. программист не только себе, но и компилятору мамой клянётся, что 3 там никак не получится. По крайней мере, у меня так вышло, может, оно и не всегда так.

SP>Причём в С++ давно нашли решение этой дилеммы. Те, кому нужна безопасность, просто обвешиваются санитайзерами и не лезут в дела других. Но конечно человек так не умеет. Ему обязательно надо рассказать остальным почему они мудаки и поступают неправильно
Я уверен, что кто-то страдает и по отсутствию автоматического приведения указателей на что угодно в указатели на что угодно, как это было в C. Уверен, что немало было по этому поводу стонов ("мамой клянусь, я знаю, что за этим void* на самом деле лежит int*, не нужно от меня требовать явного преобразования). Или по тому, что const-correctness — это прямо боль("мамой клянусь, я не буду менять объект").
И я рад, что, несмотря на эту боль, компиляторщики дали мне и ворнинг, и генерацию ud2, и другую диагностику, которой раньше не было.
Санитайзеры — сильно более другой подход, хоть и важный. Сильно влияют на характеристики производительности, на CI/CD (нужно же как-то, чтобы санитайзер у нас отработал, а клиенту поехал продукт без оного).