Date: Mon, 20 Oct 2025 11:41:07 -0400
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. "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.
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. "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.
Received on 2025-10-20 15:41:20