Are there any plans to add "expects" to std::optional?

Question

This topic is controversial, but I'm in the camp which believes that preconditions and class invariants should be guarded by asserts which terminate the program if the contract of the corresponding SW component is violated - as long as the runtime cost for the assertion checks is not a performance bottleneck.

I really like optional types and use them a lot, but for me the standard library implementations of std::optional are unusable as of now, since first the dereferencing of an optional does not perform checks whether it contains a value, and second none of the major c++ implementations support/implement assertions within standard library functions as of now.

From the use of std::optional I have seen over the years, I cannot recall a single instance where a std::optional was used in such a manner and quantity, such that precondition checks would be a performance bottleneck and prohibitive. For instance, I have never seen that somebody implemented a mask image as an array of std:optional's.

My question: Is there any proposal out already (e.g. for c++22), which adds contract features to the standard library, in particular std::optional?

---

Yes, I'm aware of the value method which is "guarded" by an exception. First, I'm not a big fan of non-exceptional control flow using exceptions (have you ever tried to debug such code). Second, I believe the strength and safety of a type should judged by its weakest link.

---

I can't comment yet, hence I comment on the answer by Nicol Bolas here:

Thanks for the answer, but I frankly I don't think it answers my question. Just to clarify. I'm not asking for a proposal which mandates that std::abort is called on contract violations (of an "expect" close). Instead, I'm asking whether there are any plans to add contract annotations to the standard library following the P0788 proposal. I agree that the standard should not mandate how specific implementations should deal with such contract violations.

Answer 1

This is kind of moot for the immediate future, since contracts was removed from C++20 for some reworking. However, I think the remaining text still applies:

Is there any proposal out already (e.g. for c++22), which adds design by contract support to the standard library, in particular std::optional?

Quite the opposite: the proposal P0788 was adopted and folded into the C++20 working paper, which states that preconditions/postconditions are not to be mandated to be implemented by the contract feature. The specific intent of P0788 was to prevent formalized requirements on implementations to use contracts for these things (or concepts for similar conditions):

Let’s avoid any specification that demands any particular technology by which implementations must comply with Library specifications.

Implementations are permitted to express such conditions as contracts, but are not required to. By adopting P0788, the committee is effectively considering such things to be a matter of implementation quality, not formal specification.

C++ is not a safe language, and contracts are not intended to make it so. Violating contracts is a programming error and yields UB, and that's how the standard sees things. And by design, there is no way for you to force your desire for safety upon those who don't want it.

Answer 2

Answer to my own question. Thanks for the discussion which pointed in the right direction.

Currently, the dereference operator of std::optional is annotated with an "Requires" clause.

In the spirit of P0788, I'd expect the Requires clause to be changed to Expects in the near future:

Let’s make it a goal, over time, to eliminate all Requires: elements from our Library specifications, preferring our new elements instead.

Furthermore, standard library implementations are permitted to any technology to meet "Expects" specifications.

3. Let’s permit an implementation to use Contracts attributes [P0542R1] and/or any other technologies to meet Expects: and Ensures: specifications.

So far, so good. Only the following statement makes it a little more tricky:

4. Let’s consider user code that relies on any specific technology on the part of an implementation to be ill-formed, with no diagnostic required

My interpretation of the above that users can't rely that standard implementations will guard Expects in any specific way or at all, but they may.

To the question:

Is there any proposal out already (e.g. for c++22), which adds contract features to the standard library, in particular std::optional?

Yes, contract annotations are already part of the standard.

It is up to the specific library implementation how to deal with "expect" clauses.