ех! хотят классную штуку попробовать в кланге и протянуть в стандарт
сейчас для этого приходиться говнокодить тип врапер обертку
хотя иногда можно и из буста поюзать
но накладно по сравнению с предлагаемым вариантом
в том виде в котором есть, надеюсь, инициативу зарубят.
Для UserId уже есть enum class
__attribute__((strong)) typedef int UserId;
enum class UserId{};
Для метров уже есть boost.units и новая поделка близко не удовлетворит потребностям.
Если сравнивать с другими языками, то это просто жалкие крохи. Например underlying типы поддерживают операцию +. Надо дать пользователю решать должен ли strong type поддерживать эту операцию. И если должен, то дать возможность переопределить. Почему подход с enum class и популярен. Он из коробки даёт операцию <=>
Как по мне, самый простой путь — доработать подход с enum class. Чтобы underlying type мог быть любым:
enum class PassportId: std::string { Invalid = "" };
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>ех! хотят классную штуку попробовать в кланге и протянуть в стандарт
Pzz>А можно ведь было бы вот так сделать, без всяких этих дурацких атрибутов:
Pzz>
Pzz>typedef protected int apples_t;
Pzz>typedef protected int oranges_t;
Pzz>
Pzz>И совместимости вроде не рушит, и выглядит осмысленно.
а вдруг уже зарезервированные кейворды нельзя юзать в других контекстах
к тому же зная по рассказам полухина как люди мыслят в комитете стандартизации
если что то вносится, то проверяют тянется ли оно
и если тянется, то начинают тянуть во все стороны
к примеру сразу начнут тянуть во все стороны эти протектед, т.е. если есть протектед значит можно и паблик и приват
пробовать, а это уже какой то треш будет
2. Глядя на то как программисты всё время кастят переменные типов enum к underlying type и обратно я сильно подозреваю, что большинству хватит набора констант:
Здравствуйте, Великий Мессия, Вы писали:
ВМ>Здравствуйте, Pzz, Вы писали:
ВМ>к примеру сразу начнут тянуть во все стороны эти протектед, т.е. если есть протектед значит можно и паблик и приват ВМ>пробовать, а это уже какой то треш будет
auto же втянули в совершенно другом смысле, чем он был задуман. Тоже могли сказать, что где auto, там и static/extern.
ВМ>атрибуты выглядят в этом плане более нейтрально
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>Здравствуйте, Pzz, Вы писали:
ВМ>>к примеру сразу начнут тянуть во все стороны эти протектед, т.е. если есть протектед значит можно и паблик и приват ВМ>>пробовать, а это уже какой то треш будет
Pzz>auto же втянули в совершенно другом смысле, чем он был задуман. Тоже могли сказать, что где auto, там и static/extern.
введя новое с С++11 они отменили старое
ВМ>>атрибуты выглядят в этом плане более нейтрально
Pzz>Они синтаксически очень громоздки.
что да то да
но в каждом компиле как помню вроде есть еще и свой набор таких атрибутов
поэтому для откатать идею хотя бы в кланге — сойдет
это шутка? Офигеть как просто. На каждый тип заводить структуру на 100 строк. enum class здесь нужен не как перечисление, а просто обёртка для типа, чтобы запретить неявные касты и дать из коробки операции сравнения. Это способ создать strong type быстро и по месту. То что вы привели — совсем из другой оперы.
Здравствуйте, Великий Мессия, Вы писали:
Pzz>>Они синтаксически очень громоздки.
ВМ>что да то да ВМ>но в каждом компиле как помню вроде есть еще и свой набор таких атрибутов ВМ>поэтому для откатать идею хотя бы в кланге — сойдет
Ну, шланг и gcc сговариваются, и у них плюс-минус одинаковый набор атрибутов. А MS живёт где-то в своей собственной вселенной...
ВМ>тогда уж какой нибудь новый кейворд
Низя. Тогда код, который использовал это слово в качестве имени переменной, резко станет невалидным. А мы так не договаривались.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>тогда уж какой нибудь новый кейворд
Pzz>Низя. Тогда код, который использовал это слово в качестве имени переменной, резко станет невалидным. А мы так не договаривались.
можно, иначе бы новых кейвордов не вводили вообще
а их вводят
Здравствуйте, Великий Мессия, Вы писали:
Pzz>>Низя. Тогда код, который использовал это слово в качестве имени переменной, резко станет невалидным. А мы так не договаривались.
ВМ>можно, иначе бы новых кейвордов не вводили вообще ВМ>а их вводят
Они имеют полное право вводить кейворды, которые начинаются с подчёрка, потому, что все символы, которые начинаются с подчёрка, зарезервированы на нужды реализации, и если вдруг какой-то из них станет недоступным, пользователю обижаться не на что.
Но кейворды с подчёрком смотрятся, как дерьмо полное.
А кейворды без подчёрка они разве когда-либо вводили?
Здравствуйте, Великий Мессия, Вы писали:
Pzz>>И впрямь. Ну что за уродский язык? Прям как Питон...
ВМ>уродство это когда весь синтаксис на пробелах построен
Это отдельное уродство, чисто питонячее.
Но принимать ломающие совместимость изменения в язык — такое себе.
Здравствуйте, Великий Мессия, Вы писали:
Pzz>>Но принимать ломающие совместимость изменения в язык — такое себе.
ВМ>совместимость снизу вверх сохраняется ВМ>именно это и является гирей С++ которая не дает ему развиваться быстрее
Ну как сохраняется? Если у тебя в программе переменная/класс/функция назывались import или export, то с того момента, как эти слова стали ключевыми, твоя программа больше не собирается.
Я не зря ведь с Питоном сравнил. Там тоже не считается чем-то зазорным, что минорное обновление версии интерпретатора запросто может сломать вполне корректную, удовлетворяющую спецификациям языка, программу.
Наверное, я слишком Go избалован. Там и совместимость не принято ломать даже по мелочи, и tytedef-ы отродясь строгие. И ключевых слов новых не вводят.
P.S. К слову сказать, в Go int и т.п. — не ключевое слово, а просто название предопределенного типа. Можно этим словом свой тип или переменную назвать. Поэтому если они добавят новый предопределенный тип, это ничего не сломает: предопределенные типы находятся в самом внешнем scope, и если такое слово определено более локально, оно так и продолжит использоваться, а если не определено, значит программа и раньше не компилировалась.
Да неужели! Не прошло и 40 лет. Хотя, погодите-ка...
> Unit confusion: meters vs yards, seconds vs milliseconds
ИМХО, для этого лучше бы подошло предложение по библиотеке units от разработчиков mp-units.
> ID confusion: mixing user IDs, product IDs, session IDs > Domain-specific types: file descriptors vs PIDs, different kinds of handles
А вот за это лайк.
Только, если правильно понимаю, официально это может оказаться разве что в C++29.
