If someone builds part of their program with one compile-time selected
semantic and another part with a different compile-time selected
semantic and then expects a consistent semantic to govern their program,
I would argue that they made a mistake.

Tom.

On 10/20/25 11:28 AM, John Spicer via SG15 wrote:
> Yes, there are lots of ways people can make mistakes and get strange
> things.
>
> The difference with contracts is you get strange things without making
> mistakes.
>
> John.
>
>> On Oct 20, 2025, at 11:26 AM, Oliver Rosten via SG21
>> <sg21_at_[hidden]> wrote:
>>
>> But I don't think it's true that it's all plain-sailing today.
>>
>> You can compile one TU with fast-math and one without. The header
>> code they consume is token-identical.
>>
>> There's no ODR violation but you can get differences depending on
>> which version the linker chooses. And these differences need not be
>> small. If the result of a floating-point calculation is used to
>> determine if a grid cell is open or closed, tiny
>> numerical differences can blow up into boolean yes/no differences.
>>
>> Isn't this something the community already lives with? Contracts may
>> increase the surface area for such things but I don't think it's novel.
>>
>> O.
>>
>> On Mon, 20 Oct 2025 at 16:19, John Spicer <jhspicer_at_[hidden]> wrote:
>>
>> By “do everything right” I meant “you don’t have an ODR violation”.
>>
>> Not that your program is perfect.
>>
>> I agree that in perfect programs you don’t need contracts.
>>
>> But for every actual program, people want contracts do what they
>> can reasonably expect that they will do.
>>
>> John.
>>
>>> On Oct 20, 2025, at 11:16 AM, Oliver Rosten via SG21
>>> <sg21_at_[hidden]> wrote:
>>>
>>> Hi John,
>>>
>>> Contracts add the new issue that you can do everything right
>>> and still get surprising behavior
>>>
>>>
>>> If you've done everything right then contracts are completely
>>> redundant in your program.
>>>
>>> O.
>>>
>>>
>>> On Mon, 20 Oct 2025 at 16:14, John Spicer <jhspicer_at_[hidden]>
>>> wrote:
>>>
>>> In general, if you do things correctly, you don’t need to
>>> understand ODR violations.
>>>
>>> If you do things incorrectly, it might be hard to figure
>>> out. But having header files mean different things in
>>> difference places is a long-standing issue that goes back to
>>> C and has always been hard to figure out.
>>>
>>> Contracts add the new issue that you can do everything right
>>> and still get surprising behavior and it is even harder to
>>> figure out because your tools won’t help you.
>>>
>>> John.
>>>
>>>> On Oct 20, 2025, at 9:56 AM, Oliver Rosten
>>>> <oliver.rosten_at_[hidden]> wrote:
>>>>
>>>> PS Most people I teach have no prior idea what an ODR
>>>> violation is.
>>>>
>>>> On Mon, 20 Oct 2025 at 14:55, Oliver Rosten
>>>> <oliver.rosten_at_[hidden]> wrote:
>>>>
>>>> That's a proof of existence but not of wide-spread usage.
>>>>
>>>> I am honestly ignorant here. As far as I know the C++
>>>> ecosystem as a whole is not making rigorous use of
>>>> things like this. But I may be wrong...
>>>>
>>>> On Mon, 20 Oct 2025 at 14:53, Ville Voutilainen
>>>> <ville.voutilainen_at_[hidden]> wrote:
>>>>
>>>> On Mon, 20 Oct 2025 at 16:46, Oliver Rosten
>>>> <oliver.rosten_at_[hidden]> wrote:
>>>> >
>>>> > Hi John,
>>>> >
>>>> > I'm not convinced by this:
>>>> >
>>>> >> No, it is not a pre-existing problem.
>>>> >> Other than contracts, if you end up with
>>>> different function definitions it is an ODR
>>>> violation and your program is IFNDR and can be
>>>> rejected by your tools.
>>>> >
>>>> >
>>>> > There's a difference between "can be in
>>>> principle" and "is in general practice". Is it not
>>>> the case that, in most instances, for all practical
>>>> purposes there is no difference between an ODR
>>>> violation that's IFNDR and the contracts
>>>> mixed-mode: you get what the linker gives you?
>>>>
>>>> See, for example,
>>>> https://devblogs.microsoft.com/oldnewthing/20160803-00/?p=94015
>>>> See
>>>> alsohttps://maskray.me/blog/2022-11-13-odr-violation-detection
>>>>
>>>
>>> _______________________________________________
>>> 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/11470.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/11472.php
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15