Date: Mon, 20 Oct 2025 18:50:22 +0300
On Mon, 20 Oct 2025 at 18:41, Joshua Berne <berne_at_[hidden]> wrote:
>
>
>
> On Mon, Oct 20, 2025 at 11:16 AM Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> <clip> Thank you for telling me that a rule that allows a conforming
>> C++ implementation to reject a mixed-mode program does not exist.
>
>
> Note for other readers that there is also no rule that says that a conforming implementation must accept a mixed-mode program.
There's no rule that such a program violates, and then it's a
fully-conforming program, so then it must be accepted. So such a rule
does very much exist.
>"Mode" and "mixing of modes" are simply not things described by the C++ standard at all
Fine, if we need to split these hairs.. ..a program consisting of
multiple TUs compiled with different implementation-defined contract
evaluation
semantics, including TUs that have multiple definitions of the same
inline functions, must be accepted. Such a rule does exist.
>> But I can tell you as a vendor of various tools including compilers,
>> that not having such a rule presents tool vendors with a difficulty.
>> And that difficulty results in a situation where IFNDR would be preferable.
> So just to be clear, what ville is saying here is that vendors "have a difficulty" doing what they already do extensively --- fail to be a conforming C++ implementation when users mix certain combinations of build flags or compilers.
That's not what I'm saying. The suggested "clarification" is
completely incorrect. Those who wish for more clarification are
welcome to send
me private emails, so that we don't spend time on a reflector where
people who do not know what they are talking about are clarifying
what other people mean by what they are saying, without having the
actual ability to do that.
> More importantly, everyone reading should consider whether IFNDR is preferable for them and their users, not just for their compiler vendor.
The reason a vendor tells you IFNDR is preferable is to provide better
tools and diagnostics for the vendor's users.
>I certainly have never encountered a case where code that cannot be reasoned about at all is preferable to code that might have one of a fixed set of well-defined behaviors.
IFNDR doesn't mean code that cannot be reasoned about at all.
>
>
>
> On Mon, Oct 20, 2025 at 11:16 AM Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> <clip> Thank you for telling me that a rule that allows a conforming
>> C++ implementation to reject a mixed-mode program does not exist.
>
>
> Note for other readers that there is also no rule that says that a conforming implementation must accept a mixed-mode program.
There's no rule that such a program violates, and then it's a
fully-conforming program, so then it must be accepted. So such a rule
does very much exist.
>"Mode" and "mixing of modes" are simply not things described by the C++ standard at all
Fine, if we need to split these hairs.. ..a program consisting of
multiple TUs compiled with different implementation-defined contract
evaluation
semantics, including TUs that have multiple definitions of the same
inline functions, must be accepted. Such a rule does exist.
>> But I can tell you as a vendor of various tools including compilers,
>> that not having such a rule presents tool vendors with a difficulty.
>> And that difficulty results in a situation where IFNDR would be preferable.
> So just to be clear, what ville is saying here is that vendors "have a difficulty" doing what they already do extensively --- fail to be a conforming C++ implementation when users mix certain combinations of build flags or compilers.
That's not what I'm saying. The suggested "clarification" is
completely incorrect. Those who wish for more clarification are
welcome to send
me private emails, so that we don't spend time on a reflector where
people who do not know what they are talking about are clarifying
what other people mean by what they are saying, without having the
actual ability to do that.
> More importantly, everyone reading should consider whether IFNDR is preferable for them and their users, not just for their compiler vendor.
The reason a vendor tells you IFNDR is preferable is to provide better
tools and diagnostics for the vendor's users.
>I certainly have never encountered a case where code that cannot be reasoned about at all is preferable to code that might have one of a fixed set of well-defined behaviors.
IFNDR doesn't mean code that cannot be reasoned about at all.
Received on 2025-10-20 15:50:37