нужны и так ли хорошо решают те проблемы, которые задуманы решать?
Насколько я понимаю, контракты суть glorified assert, в систему типов не включены, компилятор их считать не будет, а предполагается что тесты и дебаг-сборки будут гоняться с включенными контрактами, а релизные - без. Не понимаю, какие тут профиты с точки зрения бЕзОпАсНоСти или надёжности, только пролиферация режимов сборки с отличающимся поведением. Вот как на безопасность и надёжность влияет тотальное программирование, т.е. на уровне типов компилятор проверяет что программа гарантированно завершится (provably terminating), например, Idris, я понимаю, а что дают контракты в их текущем виде - нет. Особенно не понимаю почему это не часть системы типов.
во первых код будет понятнее, если есть явные пре/пост кондишны, во вторых статический анализ может это узнать, оптимизации могут это узнать и тд
Что не не нравится в современном видении комитетом контрактов — то, что на мой взгляд, они должны быть подмножеством концептов Потому что фактически вся разница между концептами и контрактами — одни выполняются в рантайме, а другие в компилтайме (и по ним можно выбрать перегрузку) Наделите контракты возможностью выбирать перегрузку функции в рантайме — мы получим и естественный violation handler (через перегрузку), и... одновременно с этим окажется, что мы получили рантайм-концепты
Ну синтаксис requires можно было бы использовать
А теперь попробуй вспомнить старые пропозалы на рефлексию со вскими constexpr void foo(std::meta::info i) requires std::meta::is_finction(i) { /* ... */ } Что это было, если не контракты?
Почему никто не предлагает синтаксис new struct чтобы создавать типы в рефлексии
Обсуждают сегодня