Да, работаем над этим.

Там большие экраны были.

Здравствуйте! Вы можете написать на почту [email protected]. Коллеги из программного комитета рассмотрят ваше предложение 😊

а с чего вы взяли что он кому-то нужен или что авторы делают его для кого-то? кто угодно может написать свой пейпер и прийти с ним в комитет. Вот люди захотели такое в C++ и они это делают. Если хотите что-то еще - вперед. Иначе слишком удобно сидеть на дивание ровно, ничего не предлагая, но критиковать людей которые прикладывают усилия чтобы что-то сделать.

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

@@GrowHobbyRU я и не говорил что каждый может добавить в C++ что захочет) Я лишь сказал что каждый может попытаться. Согласен с вашим видением языка, но для долгожителей вроде C++ это не работает. Тут всегда есть груз прошлого, который приходится тащить. Но люди стараются делать его проще и лаконичнее. По-моему - получается. И контракты эта одна из полезных фич, которую я бы хотел видеть в C++. Не знаю в таком виде или нет.

Судя по названию доклада, автор больше любитель аналитической философии а не континентальной

А как проверить рантаймовые значения не в рантайме?

@@bartolomeykant Писать обработчик. Дело в том что если требуется проверка значит нужна и корректная обработка, например бросить исключение или вернуть дефолтное значение. Если подразумевается что проверку обязуется выполнить вызывающая сторона, то глупо дублировать такие проверки. Проверки нарушения контрактов обычно выполняют упомянутым в видео assert. Если в коде нужно что-то более серьезное чем assert то на такой случай невозможно придумать стандарт, всегда будут уникальные запросы. Возможно я не правильно понял суть, или автор видело не справился и не донес идею, но то что я увидел сильно разочаровывает. Я был бы рад если бы продвигали в стандарт альтернативу макросу assert или механику позволяющую писать свои ассерты которые работали бы с модулями, но к сожалению в стандарт суют этот мусор, который отвлекает комитет от действительно важных задач. В стандарте есть отличный инструмент static_assert пусть бы развивали его, например сейчас нет простого способа вывести имя типа в лог компилятора. Обычные assert в бывают разбросанные по всему телу функции, это исключительно отладочный инструмент выполняющий роль встроенного юнит-теста, assert использует не только входные и выходные параметры а так же внутреннее состояние функции и даже глобальные данные, т.е. уже имеющийся инструмент горздо мощнее и гибче предлагаемых контрактов.

@@КошакРыжый по сути то что предлагается это asset до вызова функции, после вызова функции и можно еще несколько внутрь функции засунуть. И все это при срабатывании попадет в специальный обработчик, который один на все приложение. Для отладочных целей из этого обработчика можно напечатать стек трейс или дождаться подключения дебагерра. Больше он не зачем не нужен по сути. И этот механизм един во всем коде, какую бы стороннюю библиотеку вы не подключали. Получается вызов функции с контрактом исключает UB, так как нарушение контракта приводит к определенному поведению - крашу приложения. У меня ide мне подсказывает если я обращаюсь к значению optional без проверки, так и тут ide может предупреждать, что для вызова функции нужно сначала убедиться, что контракт соблюдается, а компилятор двойные проверки сможет оптимизировать.

kzbin.info/www/bejne/gJ7YfYpriNRnfLc

запретите русский язык, русскую культуру, россию наконец... маладец

Привыкнешь

Все так боятся этого страшного UB. Иногда хочется выписать профилактическую оплеуху очередному докладчику ругающему UB. Почему то все забывают что UB полезен, это отличный способ развязать руки опимизатору. Мы же не хотим при работе с массивом постоянно выполнять проверки выхода за массив, ведь это не бесплатная операция, вот UB и решает эту проблему. В стандарте сейчас есть std::variant который не позволяет бесплатно получить содержимое, std::get и std::get_if выполняют проверку даже если автор кода точно знает что в нем храниться. Вот какой осел до этого додумался? В том же std::optional хватило мозгов сделать небезопасный оператор *.

Пожалуйста :-) А про TSAN я уже рассказывал. Поищите на канале видео под названием "Алексей Веселовский - Анатомия ThreadSanitizer" . Но, кажется, надо сделать обновленный доклад -- во-первых там несколько поменялся алгоритм и реализация, во-вторых я не вполне удовлетворён своим докладом, как он получился. А про UBSan -- да, это следующий кандидат. Обязательно расскажу.