On 10/21/25 1:09 PM, John Spicer wrote:
> Hi Tom,
>
> I think it has been very clear that the thing that is better for the
> C++ community than what is better than what is in the C++ WP is to
> remove P2900.
>
> There is a paper to this effect:
> https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2025/p3829r0.pdf
>
> I am arguing, and I believe others are arguing, that contracts in its
> current form does not make C++ better.
>
> It also blocks later adoption of a contract feature that would make
> C++ better.
>
> So, I hope I get those bonus points!

I'm still lacking a concise and complete description of your vision for
contracts. P3829 contains some interesting ruminations, but doesn't
present a vision of what contracts should be and how they should be
used. Some of the paper is based on a misunderstanding of observed GCC
behavior. Other parts assert that some additional capabilities should be
provided (e.g., component/subsystem semantics, deep const), but no
solutions are offered. I could get behind support for Python-like
decorators, but I think they are a poor fit for expressing contracts; I
agree with the analysis in concern 15 of P3846R0. I mostly see
complaints in this paper, not an alternative vision of what contracts
can and should be.

So, no, the bonus points remain available for a serious alternative
vision and proposal.

Tom.

>
> John.
>
>> On Oct 20, 2025, at 6:38 PM, Tom Honermann <tom_at_[hidden]> wrote:
>>
>> 
>> On 10/20/25 4:57 PM, John Spicer wrote:
>>> I explicitly addressed your concern in my reply.
>>>
>>>
>>>> If you use compiler options that explicitly change the meaning
>>>> of code, then you should know what they do.
>>>>
>>>> With contracts, you use facilities that the standard endorses
>>>> and says should work fine, but you get surprising results.
>>>>
>> The C++ WP contains a recommended practice ([basic.contract.eval]p3
>> <https://eel.is/c++draft/basic.contract.eval#3>) that encourages
>> implementers to, by default, evaluate contract assertions using the
>> enforce semantic. Of course, implementers are not bound by that
>> encouragement, but I'm not aware of any expressed interest by
>> implementers to do differently (or at least not to use a semantic
>> that is not a terminating semantic as a default).
>>
>> If a portion of your program uses an extension or compiler option
>> that changes its behavior, I agree you should know what they do.
>>
>> I think the reason this is so complicated is that we have a clear
>> vision for what contracts are and what purposes they are intended to
>> support in the form of P2900 and its rationale in P2899. For those
>> that do not favor contracts in the form expressed in the C++ WP,
>> there is no clear and concise description of an alternative vision.
>> I've read every email sent to SG15, SG21, SG23, EWG, LEWG, CWG, LWG,
>> etc... I've read every contracts related paper that has been
>> published, including those in the most recent mailing and the NB
>> comments. I have engaged in private emails with some of you. I have
>> spent hours and hours while walking dogs, showering, and falling
>> asleep at night, contemplating the objections that have been
>> expressed. After recent private discussion with Ville, I think I can,
>> kind of, sort of, maybe, articulate his vision to some degree. I
>> can't do the same for Gaby, John, or anyone else that has expressed
>> concerns about contracts in its proposed form. I see complaints. I
>> see reports of problems that, as far as I can tell, are not new and
>> are not specific to contracts no matter how hard assertions to the
>> contrary are made. I see pedantic claims that P2900 doesn’t and can’t
>> support hardened preconditions because it doesn’t specify a syntax
>> (default or opt-in) to declare that a terminating semantic is
>> required for a particular contract assertion despite the C++ WP
>> specifically granting permission to implementations to provide such a
>> guarantee (real standard library implementations rely on
>> implementation provided compiler extensions and behavior, this isn’t
>> new).
>>
>> The fact that this discussion has gone on so long is clear evidence
>> to me that I am not alone in my failure to appreciate the “not that
>> complex” vision that some others seem to have.
>>
>> For those that oppose contracts in its current form, it would be very
>> helpful if you took the time to write a concise and complete
>> description of what you do want rather than complaining about what
>> you don’t. Bonus points will be awarded if that vision can be shown
>> to serve the C++ community better than what is already in the C++ WP.
>>
>> Tom.
>>
>>>
>>> John.
>>>
>>>
>>>> On Oct 20, 2025, at 4:09 PM, Oliver Rosten
>>>> <oliver.rosten_at_[hidden]> wrote:
>>>>
>>>> I’m sorry too, because it doesn’t seem that complex.
>>>>
>>>>
>>>> Well then I can only thank you for bearing with me.
>>>>
>>>> I wrote this above:
>>>>
>>>> 1. The situation in which non-inlined inline functions end up
>>>> with different semantics is not ideal.
>>>> 2. This is a manifestation of a pre-existing problem in C++
>>>>
>>>>
>>>> To which your response was:
>>>>
>>>> No, it is not a pre-existing problem.
>>>>
>>>>
>>>> I’ve given an example which I think shows that this is a
>>>> pre-existing problem. But I can’t see anywhere where you have
>>>> acknowledged this.
>>>>
>>>> As I've been at pains to say, even if you are incorrect about this
>>>> not being a pre-existing problem, I can nevertheless see why it
>>>> still concerns you. But it seems worthwhile to attempt to establish
>>>> some ground truths.
>>>>
>>>> O.
>>>>
>>>> On Mon, 20 Oct 2025 at 20:56, John Spicer <jhs_at_[hidden]> wrote:
>>>>
>>>> I’m sorry too, because it doesn’t seem that complex.
>>>>
>>>> If you use compiler options that explicitly change the meaning
>>>> of code, then you should know what they do.
>>>>
>>>> With contracts, you use facilities that the standard endorses
>>>> and says should work fine, but you get surprising results.
>>>>
>>>> I would suggest you go back to P3835 and read it more closely.
>>>>
>>>> John.
>>>>
>>>>> On Oct 20, 2025, at 3:11 PM, Oliver Rosten via SG21
>>>>> <sg21_at_[hidden]> wrote:
>>>>>
>>>>> Hi John,
>>>>>
>>>>> Sorry, but I'm still struggling to understand what you're
>>>>> trying convey.
>>>>>
>>>>> As I understand it, the rule that means the fast-math
>>>>> example above is not an ODR violation is the same as the rule
>>>>> that means Contracts mixed-mode is not an ODR violation. So I
>>>>> don't see what Contracts brings to the table that's novel, in
>>>>> this context.
>>>>>
>>>>> What one could argue is new is that Contracts provides an
>>>>> additional way for token-identical code to be compiled
>>>>> differently in different TUs.
>>>>>
>>>>> Is that what you're getting at?
>>>>>
>>>>> O.
>>>>>
>>>>> On Mon, 20 Oct 2025 at 18:26, Gabriel Dos Reis
>>>>> <gdr_at_[hidden]> wrote:
>>>>>
>>>>> The onus of the specification (the actual normative
>>>>> requirements) to reflect "intent" should be on the author
>>>>> of said intent -- irrespective of the number of
>>>>> discussions that had been had on the topic. Not the other
>>>>> way around.
>>>>>
>>>>> -- Gaby
>>>>>
>>>>> -----Original Message-----
>>>>> From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of
>>>>> Tom Honermann via SG15
>>>>> Sent: Monday, October 20, 2025 9:58 AM
>>>>> To:sg15_at_[hidden]
>>>>> Cc: Tom Honermann <tom_at_[hidden]>; Ažman Gašper
>>>>> <gasper.azman_at_[hidden]>;sg21_at_[hidden]; Joshua
>>>>> Berne <berne_at_[hidden]>; Oliver Rosten
>>>>> <oliver.rosten_at_[hidden]>;sg15_at_[hidden]
>>>>> Subject: Re: [isocpp-sg15] [isocpp-sg21] P3835 --
>>>>> Different contract checking for different libraries
>>>>>
>>>>>
>>>>> > On Oct 20, 2025, at 11:31 AM, Ville Voutilainen via SG15
>>>>> <sg15_at_[hidden]> wrote:
>>>>> >
>>>>> > On Mon, 20 Oct 2025 at 19:24, Joshua Berne
>>>>> <berne_at_[hidden]> wrote:
>>>>> >>> Everywhere. Multiple definitions of inline functions
>>>>> with different
>>>>> >>> contract evaluation semantics are ODR-equivalent,
>>>>> >> Where does the specification say that the definition of
>>>>> a contract assertion has a contract evaluation semantic?
>>>>> >
>>>>> > What part in what I wrote uttered the words "definition
>>>>> of a contract
>>>>> > assertion"?
>>>>> >
>>>>> >>> And none of that is said to be in any way
>>>>> >>> incompatible anywhere.
>>>>> >> You seem to be claiming that things that aren't defined
>>>>> are not being described as incompatible and that's a problem.
>>>>> >
>>>>> > The different evaluation semantics are defined, and
>>>>> nothing says they
>>>>> > are some incompatible parameters of the abstract machine.
>>>>> >
>>>>> >>> You can even have different evaluation
>>>>> >>> semantics for different calls of the same function,
>>>>> defined
>>>>> >>> just once, including defined in the same TU, and
>>>>> nowhere in the
>>>>> >>> standard does anything say that any of that is
>>>>> incompatible
>>>>> >>> in any way.
>>>>> >> Yes, with full flexibility to the implementation to
>>>>> define how and when that happens.
>>>>> >
>>>>> > Yes, how and when that selection of a semantic happens,
>>>>> but not that
>>>>> > the result is ill-formed.
>>>>> >
>>>>> >> Implementations are also, because they are defining
>>>>> this, perfectly able to say when the choices that dictate
>>>>> the evaluation semantics are or are not compatible with
>>>>> one another.
>>>>> >
>>>>> > They define the mechanism for that selection, but not the
>>>>> > well-formedness of the result.
>>>>> >
>>>>> >> Our specification is entirely about allowing the
>>>>> possibility of mixed modes being supported by a compiler,
>>>>> but that same allowance also gives platforms complete
>>>>> freedom to *not* support mixed modes of any sort. "Full
>>>>> stop" as you might say.
>>>>> >
>>>>> > It doesn't. It gives implementations freedom to not
>>>>> provide certain
>>>>> > selections, but it doesn't give them freedom to say that
>>>>> > using ignore here and enforce there isn't well-formed. And
>>>>> > implementations can't support just one evaluation semantic
>>>>> > everywhere, due to practical reasons.
>>>>> >
>>>>> > Your specification may be entirely about whatever fluffy
>>>>> bunnies you
>>>>> > wish, but it doesn't say what you're suggesting it says.
>>>>> >
>>>>> >>> Everywhere.
>>>>> >> Since you've failed to provide an actual citation for a
>>>>> rule in the wording itself, thank you for clarifying that
>>>>> this is not actually a rule in the specification of C++26
>>>>> contracts.
>>>>> >
>>>>> > I already gave you that rule. It's
>>>>> [intro.compliance.general]/2.1, and
>>>>> > lack of any rules being violated.
>>>>>
>>>>> I’m confident that, given the many discussions we’ve had
>>>>> on this topic, you understand the P2900 intent to be what
>>>>> Joshua stated. If not, perhaps you can accept the intent
>>>>> to be what Joshua stated given that he is one of the
>>>>> primary authors and his view is supported by many
>>>>> coauthors, including myself.
>>>>>
>>>>> Perhaps you could propose a wording change that you
>>>>> believe would make the standard better reflect that
>>>>> intent. That would be a productive outcome of this discussion.
>>>>>
>>>>> Tom.
>>>>> _______________________________________________
>>>>> SG15 mailing list
>>>>> SG15_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>>>>
>>>>> _______________________________________________
>>>>> SG21 mailing list
>>>>> SG21_at_[hidden]
>>>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>>>>> Link to this post:http://lists.isocpp.org/sg21/2025/10/11504.php
>>>>
>>>
>