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_at_[hidden]> wrote:

> On Fri, Jun 10, 2022 at 11:10 AM Hyman Rosen <hyrosen_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>