Open apolukhin opened 3 years ago
Александр Коганов, 21 марта 2019, 14:36 expects/ensures выглядит понятнее, но это вопрос привычки скорее. Зато pre/post короче. И так приходится писать длинные сигнатуры с параметрами шаблона, conditional noexcept, enable_if, хитрыми decltype(std::declval.......().function()) в типе возвращаемого значения и тп. Временами все это сразу. Получается много букв. Так что имхо спорно :)
webreh, 22 марта 2019, 3:15 expectes/ensures выглядят как два слова с одинаковыми первой, последней и количеством букв.
yndx-antoshkka, 1 апреля 2019, 13:33 Тут нужны какие-нибудь аргументы, которые не были изложены в бумаге: https://github.com/cplusplus/papers/issues/162
Если такие аргументы найдутся - можно будет возобновить обсуждение. Один из возможных аргументов: ensures, expects уже используются в тексте стандарта при описаниях поведения стандартной библиотеки. Но нужны ещё аргументы.
require/ensure используется в Eiffel.
А в контрактах SPARK используются pre и post. К тому же, в концептах уже используется requires, может возникнуть путаница и/или опечатки require{,s}.
Я за оставить pre/post в контрактах.
Контракты не приняли в C++20, а вот в стандарте слова подправили и теперь везде preconditions и postconditions, например https://eel.is/c++draft/stacktrace.entry.ctor
Шансы на то что в контрактах будут pre/post повышаются
Перенос предложения: голоса +2, -0 Автор идеи: Игорь Шаповал
Контракты не переименовывать expects/ensures на pre/post
EWG на последнем заседании по С++20 в Коне одобрила на переименовывание контрактов для предусловия и постусловия expects/ensures на pre/post. Evolution Working Group (EWG)
At the last meeting, EWG finalized the feature set for C++20. At Kona, we focused on finalizing those features:
Название pre/post не говорят что это предусловия или постусловия. Может быть уже лучше precond/postcond.
Название expects/ensures как названия для контрактов используются также в других языках.
require/ensure используется в Eiffel.
Предлагаю не переименовывать expects/ensures контракта. А добавить еще один контракт invariant для проверки полей класса.