Date: Mon, 20 Oct 2025 13:22:48 -0400
I havae already stated this on this very thread, but I’ll say it again.
These are new issues brought in by the contracts feature because it explicitly says that the dangerious things are okay to do.
No, it is not a fair reflection.
John.
> On Oct 20, 2025, at 11:57 AM, Oliver Rosten <oliver.rosten_at_[hidden]> wrote:
>
> Hi John,
>
> But can we agree that the sharp edges you're talking about aren't novel?
>
> I think the example I gave above shows this to be the case.
>
> However, I do concede that it's not trivial to conclude that it's fine for a feature that targets safety to expose these pre-existing sharp edges.
>
> Then the question becomes whether the tradeoffs are worth it.
>
> Is it a fair reflection of the discussion above to conclude that this ultimately boils down to a difference in opinion about tradeoffs, rather than novelty?
>
> O.
>
> On Mon, 20 Oct 2025 at 16:52, John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]>> wrote:
>> The problem is that the language does not provide a way to allow people to protect themselves from this situation. I would not say it is mistake because it could involve libraries written by people that have never met one another.
>>
>> IMO, it *should* be possible to lock down a semantic to a function or a “component” but it is not possible with P2900, so you have a feature with very sharp edges that are hard for people to understand.
>>
>> John.
>>
>>> On Oct 20, 2025, at 11:32 AM, Tom Honermann via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>
>>> 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]> <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto:ville.voutilainen_at_[hidden]>> wrote:
>>>>>>>>>>> On Mon, 20 Oct 2025 at 16:46, Oliver Rosten
>>>>>>>>>>> <oliver.rosten_at_[hidden] <mailto: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 also https://maskray.me/blog/2022-11-13-odr-violation-detection
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/11470.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/11472.php
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SG15 mailing list
>>>> SG15_at_[hidden] <mailto:SG15_at_[hidden]>
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>> _______________________________________________
>>> 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/11476.php
>>
These are new issues brought in by the contracts feature because it explicitly says that the dangerious things are okay to do.
No, it is not a fair reflection.
John.
> On Oct 20, 2025, at 11:57 AM, Oliver Rosten <oliver.rosten_at_[hidden]> wrote:
>
> Hi John,
>
> But can we agree that the sharp edges you're talking about aren't novel?
>
> I think the example I gave above shows this to be the case.
>
> However, I do concede that it's not trivial to conclude that it's fine for a feature that targets safety to expose these pre-existing sharp edges.
>
> Then the question becomes whether the tradeoffs are worth it.
>
> Is it a fair reflection of the discussion above to conclude that this ultimately boils down to a difference in opinion about tradeoffs, rather than novelty?
>
> O.
>
> On Mon, 20 Oct 2025 at 16:52, John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]>> wrote:
>> The problem is that the language does not provide a way to allow people to protect themselves from this situation. I would not say it is mistake because it could involve libraries written by people that have never met one another.
>>
>> IMO, it *should* be possible to lock down a semantic to a function or a “component” but it is not possible with P2900, so you have a feature with very sharp edges that are hard for people to understand.
>>
>> John.
>>
>>> On Oct 20, 2025, at 11:32 AM, Tom Honermann via SG21 <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>>>
>>> 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]> <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto: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] <mailto:ville.voutilainen_at_[hidden]>> wrote:
>>>>>>>>>>> On Mon, 20 Oct 2025 at 16:46, Oliver Rosten
>>>>>>>>>>> <oliver.rosten_at_[hidden] <mailto: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 also https://maskray.me/blog/2022-11-13-odr-violation-detection
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/11470.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/11472.php
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SG15 mailing list
>>>> SG15_at_[hidden] <mailto:SG15_at_[hidden]>
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>> _______________________________________________
>>> 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/11476.php
>>
Received on 2025-10-20 17:23:03