What I am saying is that language rules are supposed to be implemented correctly by the compiler so that people who know them and use them get the correct behavior.  Optimizationists hate that, because to them, getting a wrong result quickly is preferable to getting a correct result slowly. 

One of my major uses for volatile was to correct gcc's refusal to follow the language rules because of, naturally, optimization. When gcc compiles floating-point code using x87 instructions, it refuses to write expressions back to memory where the language definition says it should, and instead uses extended-precision values left in the floating-point registers.  That means that certain expressions that should compare equal by the rules of the language sometimes unpredictably do not.  I needed to use volatile double variables to get the correct behavior. 

As for that esoteric behavior in my example?  Tell me what foo() prints, and whether the six-month newbie will know it.

On Fri, Jun 10, 2022, 11:54 AM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Fri, Jun 10, 2022 at 11:10 AM Hyman Rosen <hyrosen@mail.com> wrote:
>
> The "sense" that a program makes is given by the rules of the language,

No, the "sense" that a program makes lives in the head of an
individual programmer based on their general understanding of how a
language works. The details of what `volatile` means are extremely
esoteric and unknown to most working programmers. As such, doing this
will not make "sense" to them.

Which is the whole point here.

You're basically saying that extremely convoluted and rarely used
language rules should be something that every programmer knows and if
they don't know them, then the programmer is the one that's wrong. I
would prefer a language that doesn't require extremely convoluted and
rarely used language rules to solve problems.

>and the rules of the language have always said, since volatile was introduced, that reading or writing a volatile variable is a side effect that is sequenced with all other side effects, and that access to volatile variables is supposed to happen by following the abstract machine. The languages said nothing to differentiate automatic volatiles from any other volatiles.
>
> It is not esoteric nonsense to expect a program to behave the way the language specifies.  And it is not as if the C++ committee hasn't added enormous amounts of esoteric nonsense to the language that people are expected to understand.  Here's my favorite:
>
> int &a() { printf("a"); static int i; return i; }
> Int &b() { printf("b"); static int i; return i; }
> void foo() {
>     a() <<= b();
>     a() << b();
>     a() < b();
> }

I'm not sure what exactly is "esoteric" (meaning "understood by or
meant for only the select few who have special knowledge or interest")
here. With the exception of whether the `static int i;` declaration
will zero-initialize `i`, there is nothing about this that I would
consider "esoteric". It's definitely weird, but it is a natural
outgrowth of:

1. How references work.
2. How local static variables work.
3. What those operators actually do.

None of which is particularly "esoteric". I would expect any C++
programmer who finished their first 6 months of study in the language
to be able to work out what this program does.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals