这个主题是有争议的，但是我认为，前提条件和类不变式应该由断言来保护，如果违反了相应的SW组件的约定，则断言会终止程序-只要运行时的代价是断言检查不是性能瓶颈。
我真的很喜欢可选类型，并经常使用它们，但是对我来说，std :: optional的标准库实现目前不可用，因为第一个the dereferencing of an optional does not perform checks whether it contains a value和第二个主要c ++实现都不支持/到目前为止，在标准库函数中实现断言。
根据我多年来看到的std :: optional的使用，我无法回忆起一个实例，其中以这样的方式和数量使用std :: optional，因此前提条件检查将成为性能瓶颈，并且令人望而却步。 。例如，我从未见过有人将遮罩图像实现为std：optional的数组。
我的问题：是否已经有提案（例如针对c ++ 22），该提案将contract features添加到标准库中，尤其是std :: optional？
是的，我知道value方法受到异常的“保护”。 首先，我不喜欢使用异常（have you ever tried to debug such code）的非异常控制流。 第二，我认为类型的强度和安全性应该通过其最弱的环节来判断。
我无法发表评论，因此我在这里对Nicol Bolas的回答发表评论：
感谢您的回答，但坦率地说，我认为它不能回答我的问题。只是为了澄清。我不是要求提出一项提案，该提案要求在违反合同（“期望”关闭）时调用std :: abort。相反，我要问的是，在P0788提议之后，是否有任何计划将合同注释添加到标准库中。我同意该标准不应强制规定特定的实施方式应如何处理此类违约情况。
答案 0 :(得分：8)
是否已经有提案（例如对于c ++ 22），该提案将合同支持的设计添加到标准库中，尤其是std :: optional？
恰恰相反：proposal P0788被采用并且folded into the C++20 working paper被声明，前提条件/后置条件不是 要由合同功能强制执行。 P0788的具体意图是防止对实现的正式要求，以将合同用于这些事物（或类似条件的概念）：
我们避免使用任何要求任何特定技术的规范，而这些规范要求实现必须符合库规范。
允许执行来表达诸如合同之类的条件，但并非必须如此。通过采用P0788，委员会正在有效地将这些事情视为实现质量的问题，而不是正式的规范。
C ++不是一种安全的语言，合同也不打算这样做。违反合同是编程错误，并产生UB，这就是标准看待事物的方式。而且，通过设计，您无法将对安全的渴望强加给那些不想要的人。
答案 1 :(得分：0)
回答我自己的问题。感谢您的讨论指出了正确的方向。
当前，std :: optional的解除引用运算符用"Requires" clause注释。
本着P0788的精神，我希望Requires子句在不久的将来会更改为Expects：
让我们逐渐成为消除所有Requires：元素的目标 规范，而不是我们的新元素。
此外，允许标准库实现使用 任何 技术来满足“期望”规范。
- 我们允许实施使用合同属性[P0542R1]和/或任何其他属性 满足期望并确保：规范的技术。
到目前为止，太好了。仅以下语句使它更加棘手：
- 让我们考虑依赖于实施中任何特定技术的用户代码，它们的格式都是错误的，不需要进行诊断
我对上述内容的解释是，用户不能依靠标准实现以任何特定方式或根本无法保护Expects，但是它们可以。
问题：
是否已经有提案（例如针对c ++ 22），该提案将合同功能添加到标准库中，尤其是std :: optional？
是的，合同注释已经是标准的 部分。
如何处理“期望”子句取决于具体的库实现。