Why is it recommended not to allow querying the contract level for C++20 Contracts?

Question

The current C++ draft contains, in [dcl.attr.contract.check] p3:

There should be no programmatic way of setting, modifying, or querying the build level of a translation unit.

I don't understand why it is recommended to not allow querying the contract level. With the current assert macro it is possible to detect if the assert is used via the NDEBUG macro.

Querying the contract level is useful in some cases like:

• adding additional variables to track additional state.
• transforming atomic store in atomic compare exchange to read the value.

what is the rationale behind recommending that querying the build level not be possible?

Answer 1

It is recommended that implementations not provide such a query because it would break mixed check-level usage.

As it currently stands, there is nothing formally wrong with building a library under one check-level, and linking it to code built under another. However, if code could easily query which check-level is available, that would potentially break this use case. Such a query can be used to affect the ABI of types and so forth. If the library has such an interface, then you have to build the consuming code under the same check-level, so that any headers and such would define the same ABI.

Is it possible to use such a query in a way that doesn't affect ABI and interfaces? Sure. But providing a test makes it way too easy to bungle.

As it currently stands, you can have a library have its own test, a #define which is expected to be defined when compiling under a particular checking level or somesuch. But such a define now is a part of your library's building interface. That's just part of your build documentation; if people build your library under check-level X, they must provide a #define. And any code consuming a library built under such circumstances must also provide that define.

And that's best part: the consuming code does not have to share your check-level. They have to share your define, but not the actual check-level. Your define belongs to the library; the check-level belongs to the user.