On Mon, Oct 20, 2025 at 11:16 AM Ville Voutilainen <ville.voutilainen@gmail.com> 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.  "Mode" and "mixing of modes" are simply not things described by the C++ standard at all, they are properties of a compiler invocation, and whether different compiler invocations with different such properties come together to be a conforming C++ implementation is up to those vendors to define.

 
That was what I was looking for. I do not need help in implementing
non-conforming facilities, nor do I need explanations what they are
and what that means, and few if any other vendors do.

Please forgive me for implying that I was responding for your sake.  I am clarifying things so that others reading this thread don't see a citation of the standard and then interpret it as some form of gospel indicating that there is some form of insurmountable problem here.

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 certainly shocking if true.    I have more faith in our vendors to provide the capabilities and restrictions that their users ask of them.   If someone wants a platform where mixed modes are not allowed, they will get it and any use of that platform without mixing modes will be a use of a conforming platform ("full stop" as Ville enjoys saying in his paper titles.)

More importantly, everyone reading should consider whether IFNDR is preferable for them and their users, not just for their compiler vendor.   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.