I think some, but certainly not all, participants in this thread may have taken the novelty and controversy of the contracts feature to indicate that the old ways of managing build configurations no longer apply.

The old ways still apply. The contracts design, by design, does not interfere.

Library producers are free to configure their libraries. A library may be produced in a single configuration, or in several configurations, which can be distinguished by name. For example, a library producer might use the source of a library “libfoo” to produce “libfoo_fast.lib,” “libfoo_verbose.lib,” and “libfoo_hardened.lib,” all exporting the same symbols.

A client of the library then indicates their chosen configuration by naming it in the link command.

This hasn’t changed: a client without access to the library source can’t produce a new configuration of the library.

This has improved: with C++26 contracts, a client’s contract configuration choices for their own code are not limited by the options chosen for the libraries they depend upon.

This has also improved: with C++26 contracts, pre- and postconditions may be expressed on the library boundary and may be checked in the library, in the client, or both. Doing so requires further implementation work, and doing so well requires more detailed compiler options, which the best implementations will come to an agreement on. (To see one idea for what that might look like, see my talk “Perspectives on Contracts.”)

Now I don’t mean to say that the old ways are always the best ways, but I perceive a lot of scrambling for new solutions in this area. I don’t think this scramble for improvement should obscure the value of the old ways.

  —Lisa