On 10/22/25 10:26 AM, John Spicer via SG21 wrote:
> That still fails to do what i want, which is to have the library
> provide know that the semantic they choose will be the one used when
> the program is linked.

The following question is, again, intended as a serious one.

Why do you want to use contracts to provide that guarantee?

 From my perspective, an unconditional-always-enforce contract semantic
changes a function that has a narrow contract into a function that has a
wide contract (or at least a wider contract subject to contracts that
are actually expressible in the language). Contracts aren't needed to do
that; we can express wider contracts in code today. Is the desire based
on wanting integration with a contract violation handler? Or a desire to
express hardened preconditions in the function interface so that they
are available for static analysis or caller-side optimization?

Assuming those capture your motivation, how far would support for a
syntax like the following go towards satisfying your desire?

    int* find(int *begin, int *end, int item)
       pre *hardened* (begin != nullptr) // Hardened preconditions;
       pre *hardened* (end != nullptr) // always evaluated with a
       pre *hardened* (begin <= end) // terminating contract semantic.
       pre (is_sorted(begin, end) // Not a hardened precondition.
    ;

>
> It also sounds like this is mostly a variant of runtime semantic
> selection, which requires the code for all possible semantic varients
> to be emitted, which is a non-starter for most production code.

For what it is worth, I agree that is a non-starter for most production
code with the linkers and loaders in use today.

This is a bit of a tangent, but my expectation, based on post link
optimization work I'm aware of but can't talk about, is that future
linkers and loaders will be able to support optimizing at load-time
based on a load-time selected contract semantic (similar to JIT
enablement of Java assertions by JVMs). I can't promise that such
technologies will ever be deployed of course or on any meaningful
timeline. I want to ensure the C++ standard does not prohibit use of
such future optimization possibilities by requiring a compile-time
selected semantic by default (I'm ok with an explicit opt-in as in the
example above).

Tom.

>
> John.
>
>> On Oct 20, 2025, at 7:33 AM, Gašper Ažman <gasper.azman_at_[hidden]> wrote:
>>
>> You can definitely do it with conventional linkers. You guard the
>> check with a link-time constant semantic at code emission; you let
>> the linker fill those in. The link-time constant is a global that the
>> linker deduplicates.
>>
>> You can also introduce additional labels that skip the checks in the
>> preconditions, and let the linker resolve the calls to those. Normal
>> linkers do this. It works for weak symbols too.
>>
>> On Mon, Oct 20, 2025 at 11:57 AM John Spicer <jhspicer_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]> 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]> 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
>>>
>>> _______________________________________________
>>> 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/11422.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/11687.php