Date: Tue, 21 Oct 2025 13:09:00 -0400
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!
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]> <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto:sg15-bounces_at_[hidden]>> On Behalf Of Tom Honermann via SG15
>>>>>> Sent: Monday, October 20, 2025 9:58 AM
>>>>>> To: sg15_at_[hidden] <mailto:sg15_at_[hidden]>
>>>>>> Cc: Tom Honermann <tom_at_[hidden] <mailto:tom_at_[hidden]>>; Ažman Gašper <gasper.azman_at_[hidden] <mailto:gasper.azman_at_[hidden]>>; sg21_at_[hidden] <mailto:sg21_at_[hidden]>; Joshua Berne <berne_at_[hidden] <mailto:berne_at_[hidden]>>; Oliver Rosten <oliver.rosten_at_[hidden] <mailto:oliver.rosten_at_[hidden]>>; sg15_at_[hidden] <mailto: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] <mailto:sg15_at_[hidden]>> wrote:
>>>>>> >
>>>>>> > On Mon, 20 Oct 2025 at 19:24, Joshua Berne <berne_at_[hidden] <mailto: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] <mailto:SG15_at_[hidden]>
>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>>>> _______________________________________________
>>>>> SG21 mailing list
>>>>> SG21_at_[hidden] <mailto: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
>>>>
>>
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!
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]> <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto:sg15-bounces_at_[hidden]>> On Behalf Of Tom Honermann via SG15
>>>>>> Sent: Monday, October 20, 2025 9:58 AM
>>>>>> To: sg15_at_[hidden] <mailto:sg15_at_[hidden]>
>>>>>> Cc: Tom Honermann <tom_at_[hidden] <mailto:tom_at_[hidden]>>; Ažman Gašper <gasper.azman_at_[hidden] <mailto:gasper.azman_at_[hidden]>>; sg21_at_[hidden] <mailto:sg21_at_[hidden]>; Joshua Berne <berne_at_[hidden] <mailto:berne_at_[hidden]>>; Oliver Rosten <oliver.rosten_at_[hidden] <mailto:oliver.rosten_at_[hidden]>>; sg15_at_[hidden] <mailto: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] <mailto:sg15_at_[hidden]>> wrote:
>>>>>> >
>>>>>> > On Mon, 20 Oct 2025 at 19:24, Joshua Berne <berne_at_[hidden] <mailto: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] <mailto:SG15_at_[hidden]>
>>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>>>> _______________________________________________
>>>>> SG21 mailing list
>>>>> SG21_at_[hidden] <mailto: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
>>>>
>>
Received on 2025-10-21 17:09:15