On 6/2/25 5:46 PM, Ville Voutilainen wrote:
> On Mon, 2 Jun 2025 at 23:44, Tom Honermann<tom_at_[hidden]> 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"
I didn't suggest that.
> 2) a semantics selection mechanism can't select something that's not
> an available semantic
It can as a non-conforming extension.
> 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
Of course.
> 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.
Agreed.
>
> 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.