> On Oct 4, 2025, at 5:04 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> On Sun, 5 Oct 2025 at 01:56, Lisa Lippincott via Ext
> <ext_at_[hidden]> wrote:
>
>> 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.
>
> Considering that all that was always implementation-defined, it's
> questionable whether we can make such promises. Such promises became
> even further
> questionable by the introduction of the quick_enforce semantic.

You are technically correct, which is, of course, the best kind of correct. The C++26 contracts design allows such independence, whether quick_enforce is used or not. Implementations retain the ability to peevishly deny such independence.


>> 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.”)
>
> I'm somewhat curious what this suggested implementation work is, what
> those options are, and mire importantly what, if anything, beyond that
> talk, these
> assessments are based on.

I am also curious. My impression from the SG15 meetings I’ve attended is that it’s things like “find out what user controls are provided in similar ways by more than one compiler” and “agree upon uniform ways to spell the corresponding compiler flags.”

  —Lisa