On Mon, 2 Jun 2025 at 23:44, Tom Honermann <tom@honermann.net> wrote:

It's fairly easy to find WG21 members who think it's absolutely
necessary to have "more in-source syntax" to decide the difference
between a contract
that scales its behavior from full checking to almost-nothing, and a
contract that scales its behavior from full checking to almost-nothing
and onwards
to assumption of the condition stated in the contract.

I assume you are referring to an in-source mechanism to select a contract semantic along the lines of those proposed in P3400 (Controlling Contract-Assertion Properties). If so, I agree.

Funny choice of words, "assume". :D

My statement regarding not seeing a need for more in-source syntax is based on a perception that [[assume(expr)]], inline functions, and a facility to control the contract semantic (whether in-source or otherwise) suffices to provide the benefits the proposer seeks.

Well,
1) if we make [[assume]] usable on function declarations or in
particular function parameters, we have already arrived at "more
in-source syntax"

2) a semantics selection mechanism can't select something that's not
an available semantic

3) if we make 'assume' such a semantic, there's going to be opposition
to allow it as a possible implementation-chosen semantic for the C++26
contracts syntax

4) and it's likely that even if we end up standardizing an in-source
semantics-selection syntax, there's likely going to be people in WG21
who will want
a syntax that without any possibility of plugging otherwise prevents
choosing an 'assume' semantic, no matter what the mechanism triggered
by the in-source
selection syntax attempts to do.

You may not think such additional syntax is necessary. But there are
people in WG21 who do.

Therefore I would be hesitant to suggest that WG21 has made up its
mind on this matter, and it's a fruitless exercise to entertain "more
in-source syntax" to
enable such assumptions. Some WG21 members are going to insist that
such more-syntax is used for it.

I made no such suggestion. What I offered was my personal opinion.

I think something like the following suffices for what was proposed.

double compute_sqrt(double arg) pre (arg > 0.0); inline double sqrt(double arg) { if (arg < -0.0) return std::numeric_limits<double>:: quiet_NaN(); if (arg == 0.0 /* or is +/- infinity or is a NaN*/) return arg; return compute_sqrt(arg); } double get_definite_positive_value() post(r: r >= 0.0); double f() { double d = get_definite_positive_value(); return sqrt(d); }

I understand that this doesn't address (some of) what the proposer wanted since it requires that the checks to be optimized away are exposed in the TU where the call is made. However, that constraint is also present in the technical specifications of the proposal.

Tom.