For a variety of reasons, using weird compiler options is not tenable
across an organization.

I only replied because "optimizationists" were mentioned. Having argued
years ago until I was figuratively blue in the face for strict left-to-
right order of evaluation to absolutely no avail, I have given up on
expecting my point of view to ever go anywhere. If I needed a last straw,
eliding access to automatic volatile variables was it.

I'm retired now, so I don't have to deal with this stuff any more. It's my
son's turn now :-)

I still love to point out the order of evaluation abomination that is

int &a();
int &b();

a() <<= b();
a() << b();
a() < b();

On Mon, Aug 28, 2023, 8:44 AM Alejandro Colomar <alx.manpages_at_[hidden]>
wrote:

> Hi Hyman,
>
> On 2023-08-28 09:12, Hyman Rosen via Std-Proposals wrote:
> > I'm the "optimizationist" guy.
>
> [... blaming the ISO C++ dialect ...]
>
> >
> > Order of evaluation should be strictly left-to-right for all expressions.
> >
> > The whole notion that executing undefined behavior makes the behavior of
> > the entire program unspecified, and therefore allows compilers to pretend
> > that undefined behavior is never executed, is completely wrongheaded. At
> > the very least, it should be required that all side effects that would
> have
> > been encountered by the abstract machine ahead of the undefined behavior
> > must occur. The best thing would be to incorporate Ada's notion of
> "bounded
> > errors", where many things now specified as undefined behavior would
> become
> > defined to produce a range of possible outcomes, with the program
> > continuing to execute in most cases.
>
> This dialect of C++ that you like does exist. It is non-standard, because
> it seems not all programmers agree with it (I don't like this dialect, for
> example). But if you want to talk that dialect, nothing is forcing you to
> talk ISO C++.
>
> $ g++ -O0 -fno-strict-overflow -fwrapv -fno-trapv -fno-strict-aliasing
>
> If your compiler doesn't support that dialect, then change your compiler.
> You're basically asking for C++-like assembly dialect, which is a fair ask.
>
> Cheers,
> Alex
>