On 10/23/25 4:31 PM, John Spicer wrote:
> I want to provide the guarantee because I want to be able to have
> checks that I know are enforced.
>
> If I don’t know they are enforced, then I’ll keep using my macro-based
> solution where I know that they are.
>
> As an example, the EDG front end can be built as a library, and to use
> it, you need to include some EDG header files.
>
> I don’t want my checks to go away because the user of the library
> chose a different semantic.
>
> I hope that answers the question. If not, let me know.

I understand that you want those guarantees; I'm not questioning that.

I'm still interested in whether a syntax like the one I suggested
suffices to provide that guarantee. If not, how does it fall short?
Assume that the syntax (however spelled) is applicable to pre, post, and
contract_assert.

Tom.

>
> John.
>
>> On Oct 23, 2025, at 12:21 PM, Tom Honermann via SG21
>> <sg21_at_[hidden]> wrote:
>>
>> 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
>> _______________________________________________
>> 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/11701.php
>