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]> 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]>
> 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]> wrote:
>
>>
>> On Oct 17, 2025, at 10:23 AM, Harald Achitz via SG21 <
>> 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]> 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
>>
>>
>> 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]
>> 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]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> Link to this post: http://lists.isocpp.org/sg21/2025/10/11352.php
>
>
>