Date: Mon, 20 Oct 2025 09:03:51 -0400
P2900 has quite a few novel features that, IMO, do not have sufficient deployment experience to be confident that they are right.
These have been detailed in a number of papers, so I won’t repeat tghem here.
Based on the problem that has been described here, and the lack of sufficient experience with the other novel aspects, I think a white paper is the way to go at this point.
John.
> On Oct 20, 2025, at 7:28 AM, Timur Doumler via SG21 <sg21_at_[hidden]> wrote:
>
> Hi John,
>
> I agree that the problem you highlighted exists. I don't think anybody dismisses the existence of the problem. However, as described in P3846, the fundamental cause of the problem is the way in which the C++ compilation model works, and not anything specific to contracts, and in fact *any* feature that lets you change the semantic of code at build time inevitably runs into the same problem (and many existing macros and semantic-modifying compiler flags do have that problem today and are stil being widely used).
>
> Now, as described in P3846, there are only three ways to address the problem:
>
> (1) Accept that the problem exists and standardise P2900 anyway because it provides value to users despite the existence of the problem,
>
> (2) Change P2900 to require deterministic semantics across TUs, which means the feature will not work with existing toolchains, which in turn means nobody will adopt it,
>
> (3) Not standardise P2900 or any other such feature at all.
>
> John, I get that you are arguing against (1) as you seem to think the value provided by P2900 doesn't outweigh the gravity of the problem, but I don't understand if you argue for (2) or (3)? Or do you see an option (4) and if yes, what does that look like? Please clarify.
>
> Thanks,
> Timur
>
>> On 20 Oct 2025, at 13:04, Oliver Rosten via SG15 <sg15_at_[hidden]> wrote:
>>
>>
>> To try to avoid the risk of going around in circles, John, can I confirm that my understanding of your position is correct.
>>
>> First, *I think* that everyone agrees on the following two points
>> 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++
>>
>> I think we also all agree on the 3rd point:
>> 3. Contracts increases the surface area of exposure to this problem
>>
>> If I'm on the right track so far then is it fair to say that the bone of contention boils down to this?
>>
>> The weight each of us ascribes to the benefits of P2900 over the drawback of point 3. is different?
>>
>> John, I assume you see at least some value in P2900 (i.e. it's not completely worthless in your opinion, though correct me if I'm wrong). However, you see (amongst other things such as constification but that's a different discussion) that increased exposure to 3. outweighs any benefits of P2900 in your mind?
>>
>> O.
>>
>> On Mon, 20 Oct 2025 at 11:58, John Spicer via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>> That assumes facilities that linkers might not have, and even if they have them, it may require expert use to select the version of the function you want.
>>>
>>> This also potentially requires you to *know* which functions you and your libraries use.
>>>
>>> On most systems with conventional linkers you do not have the capability you describe.
>>>
>>> John.
>>>
>>>> On Oct 20, 2025, at 6:52 AM, Gašper Ažman via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>
>>>> John,
>>>>
>>>> it shouldn't be "assigned randomly" - it's at best a final link-time property (as specified). The final link (+LTO) can do it.
>>>>
>>>> On Mon, Oct 20, 2025 at 11:50 AM John Spicer <jhspicer_at_[hidden] <mailto:jhspicer_at_[hidden]>> wrote:
>>>>> The problem is that for function templates, member functions of class templates, and inline functions, the semantic is essentially assigned randomly if it is used in multiple TUs that are compiled with different semantics.
>>>>>
>>>>> In most complex environments you are dealing with things like libraries that are provided by others, so you may not have control over how it is built.
>>>>>
>>>>> You can also have two libraries that use a third library, but if those two libraries are a different semantic any user of the third library has no idea what semantic they’ll get even if their code also uses the third library and is built with a particular semantic.
>>>>>
>>>>> John.
>>>>>
>>>>>> On Oct 17, 2025, at 11:45 AM, Gašper Ažman via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>>>
>>>>>> +1 to what Tom said.
>>>>>>
>>>>>> One part of this discussion is speaking as if semantics are assigned randomly or arbitrarily, where they are assigned by the person who ships the product - it has been pointed out time and time again that the actor deploying the application is the final arbiter of what "safe" means for a given contract check, because it's actually a function of "safe(context) -> bloom" (where "bloom" is a type with exactly two values of "no" and "perhaps").
>>>>>>
>>>>>> The stakeholder with the best context is the deployer of the application; the farther away you go from that stakeholder, the less context they have. Deferring the choice of semantic to as late as possible gives a better outcome.
>>>>>>
>>>>>> On Fri, Oct 17, 2025 at 4:33 PM Tom Honermann via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>>>>
>>>>>>>> On Oct 17, 2025, at 10:23 AM, Harald Achitz via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2025-10-17 16:00, René Ferdinand Rivera Morell wrote:
>>>>>>>>> On Fri, Oct 17, 2025 at 8:53 AM Harald Achitz via SG15 <sg15_at_[hidden] <mailto:sg15_at_[hidden]>> wrote:
>>>>>>>>>> Today's
>>>>>>>>>>
>>>>>>>>>> void fun(Foo* ptr) {
>>>>>>>>>> my_supper_assert_macro (ptr!=nullpter);
>>>>>>>>>> my_supper_assert_macro(ptr->hasData());
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> should not have any problems, ever
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> AFAIU, if my_supper_assert_macro implements something equivalent to observe, that is still UB at present. Or is it EB now?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -- René Ferdinand Rivera Morell
>>>>>>>>> -- Don't Assume Anything -- No Supongas Nada
>>>>>>>>> -- Robot Dreams - http://robot-dreams.net <http://robot-dreams.net/>
>>>>>>>> On devices that keep you alive, one example where I have seen such super asserts in action, contracts are contracts They do not exist only sometimes.
>>>>>>>>
>>>>>>> Correct, (plain language) contracts are omnipresent. The contract checking statements above violate the function contract and are thus defective. Static analysis can diagnose such cases. For example, I would expect a contracts enabled version of Coverity to report a FORWARD_NULL issue for the above code.
>>>>>>>>
>>>>>>>> I am not even sure if contracts as specified would pass regulatory requirements, I think not.
>>>>>>>>
>>>>>>> I’m not an expert on the subject by any means, but I would expect regulatory requirements to consider the manner in which the software is built; just as they consider the content of the source code and require other supply chain guards. A requirement that deployed software not contain portions for which the observe semantic is selected seems reasonable and prudent.
>>>>>>>
>>>>>>> Tom.
>>>>>>>> /Harald
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/11351.php
>>>>>> _______________________________________________
>>>>>> 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/11352.php
>>>>>
>>>> _______________________________________________
>>>> 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/11422.php
>>>
>>> _______________________________________________
>>> 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/11424.php
>> _______________________________________________
>> 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/11426.php
These have been detailed in a number of papers, so I won’t repeat tghem here.
Based on the problem that has been described here, and the lack of sufficient experience with the other novel aspects, I think a white paper is the way to go at this point.
John.
> On Oct 20, 2025, at 7:28 AM, Timur Doumler via SG21 <sg21_at_[hidden]> wrote:
>
> Hi John,
>
> I agree that the problem you highlighted exists. I don't think anybody dismisses the existence of the problem. However, as described in P3846, the fundamental cause of the problem is the way in which the C++ compilation model works, and not anything specific to contracts, and in fact *any* feature that lets you change the semantic of code at build time inevitably runs into the same problem (and many existing macros and semantic-modifying compiler flags do have that problem today and are stil being widely used).
>
> Now, as described in P3846, there are only three ways to address the problem:
>
> (1) Accept that the problem exists and standardise P2900 anyway because it provides value to users despite the existence of the problem,
>
> (2) Change P2900 to require deterministic semantics across TUs, which means the feature will not work with existing toolchains, which in turn means nobody will adopt it,
>
> (3) Not standardise P2900 or any other such feature at all.
>
> John, I get that you are arguing against (1) as you seem to think the value provided by P2900 doesn't outweigh the gravity of the problem, but I don't understand if you argue for (2) or (3)? Or do you see an option (4) and if yes, what does that look like? Please clarify.
>
> Thanks,
> Timur
>
>> On 20 Oct 2025, at 13:04, Oliver Rosten via SG15 <sg15_at_[hidden]> wrote:
>>
>>
>> To try to avoid the risk of going around in circles, John, can I confirm that my understanding of your position is correct.
>>
>> First, *I think* that everyone agrees on the following two points
>> 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++
>>
>> I think we also all agree on the 3rd point:
>> 3. Contracts increases the surface area of exposure to this problem
>>
>> If I'm on the right track so far then is it fair to say that the bone of contention boils down to this?
>>
>> The weight each of us ascribes to the benefits of P2900 over the drawback of point 3. is different?
>>
>> John, I assume you see at least some value in P2900 (i.e. it's not completely worthless in your opinion, though correct me if I'm wrong). However, you see (amongst other things such as constification but that's a different discussion) that increased exposure to 3. outweighs any benefits of P2900 in your mind?
>>
>> O.
>>
>> On Mon, 20 Oct 2025 at 11:58, John Spicer via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>> That assumes facilities that linkers might not have, and even if they have them, it may require expert use to select the version of the function you want.
>>>
>>> This also potentially requires you to *know* which functions you and your libraries use.
>>>
>>> On most systems with conventional linkers you do not have the capability you describe.
>>>
>>> John.
>>>
>>>> On Oct 20, 2025, at 6:52 AM, Gašper Ažman via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>
>>>> John,
>>>>
>>>> it shouldn't be "assigned randomly" - it's at best a final link-time property (as specified). The final link (+LTO) can do it.
>>>>
>>>> On Mon, Oct 20, 2025 at 11:50 AM John Spicer <jhspicer_at_[hidden] <mailto:jhspicer_at_[hidden]>> wrote:
>>>>> The problem is that for function templates, member functions of class templates, and inline functions, the semantic is essentially assigned randomly if it is used in multiple TUs that are compiled with different semantics.
>>>>>
>>>>> In most complex environments you are dealing with things like libraries that are provided by others, so you may not have control over how it is built.
>>>>>
>>>>> You can also have two libraries that use a third library, but if those two libraries are a different semantic any user of the third library has no idea what semantic they’ll get even if their code also uses the third library and is built with a particular semantic.
>>>>>
>>>>> John.
>>>>>
>>>>>> On Oct 17, 2025, at 11:45 AM, Gašper Ažman via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>>>
>>>>>> +1 to what Tom said.
>>>>>>
>>>>>> One part of this discussion is speaking as if semantics are assigned randomly or arbitrarily, where they are assigned by the person who ships the product - it has been pointed out time and time again that the actor deploying the application is the final arbiter of what "safe" means for a given contract check, because it's actually a function of "safe(context) -> bloom" (where "bloom" is a type with exactly two values of "no" and "perhaps").
>>>>>>
>>>>>> The stakeholder with the best context is the deployer of the application; the farther away you go from that stakeholder, the less context they have. Deferring the choice of semantic to as late as possible gives a better outcome.
>>>>>>
>>>>>> On Fri, Oct 17, 2025 at 4:33 PM Tom Honermann via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>>>>
>>>>>>>> On Oct 17, 2025, at 10:23 AM, Harald Achitz via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2025-10-17 16:00, René Ferdinand Rivera Morell wrote:
>>>>>>>>> On Fri, Oct 17, 2025 at 8:53 AM Harald Achitz via SG15 <sg15_at_[hidden] <mailto:sg15_at_[hidden]>> wrote:
>>>>>>>>>> Today's
>>>>>>>>>>
>>>>>>>>>> void fun(Foo* ptr) {
>>>>>>>>>> my_supper_assert_macro (ptr!=nullpter);
>>>>>>>>>> my_supper_assert_macro(ptr->hasData());
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> should not have any problems, ever
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> AFAIU, if my_supper_assert_macro implements something equivalent to observe, that is still UB at present. Or is it EB now?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -- René Ferdinand Rivera Morell
>>>>>>>>> -- Don't Assume Anything -- No Supongas Nada
>>>>>>>>> -- Robot Dreams - http://robot-dreams.net <http://robot-dreams.net/>
>>>>>>>> On devices that keep you alive, one example where I have seen such super asserts in action, contracts are contracts They do not exist only sometimes.
>>>>>>>>
>>>>>>> Correct, (plain language) contracts are omnipresent. The contract checking statements above violate the function contract and are thus defective. Static analysis can diagnose such cases. For example, I would expect a contracts enabled version of Coverity to report a FORWARD_NULL issue for the above code.
>>>>>>>>
>>>>>>>> I am not even sure if contracts as specified would pass regulatory requirements, I think not.
>>>>>>>>
>>>>>>> I’m not an expert on the subject by any means, but I would expect regulatory requirements to consider the manner in which the software is built; just as they consider the content of the source code and require other supply chain guards. A requirement that deployed software not contain portions for which the observe semantic is selected seems reasonable and prudent.
>>>>>>>
>>>>>>> Tom.
>>>>>>>> /Harald
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/11351.php
>>>>>> _______________________________________________
>>>>>> 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/11352.php
>>>>>
>>>> _______________________________________________
>>>> 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/11422.php
>>>
>>> _______________________________________________
>>> 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/11424.php
>> _______________________________________________
>> 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/11426.php
Received on 2025-10-20 13:04:07