Fun surprising things

[Jonathan M Davis]

On Thursday, November 1, 2018 1:42:27 AM MDT Brad Roberts via Digitalmars-d 
wrote:
> On 10/31/2018 10:57 PM, Jonathan M Davis via Digitalmars-d wrote:
> > On Wednesday, October 31, 2018 10:58:55 PM MDT Neia Neutuladh via
> >
> > Digitalmars-d wrote:
> >> Except that's only applicable if the spec doesn't define the
> >> appropriate
> >> order of evaluation.
> >
> > The spec defines left-to-right evaluation, but since _most_ programming
> > languages don't define the order of evaluation so that the compiler can
> > efficiently reorder operations, I'd honestly argue that it's just plain
> > bad practice in general to rely on the order of evaluation of
> > expressions like this. It's the sort of thing that's just begging for
> > trouble. Sure, if D defines it, plays by its own rules properly, you
> > understand its rules properly, and you write your code accordingly, you
> > can theoretically avoid problems, but if you get in the habit of
> > writing such code, you're just begging to shoot yourself in the foot as
> > soon as you have to write code in any other language. And even within
> > D, if the expression is complicated, the exact order of operations can
> > get hard to understand. So, writing anything that's even vaguely like
> > foo() + bar() where foo() or bar() depend on one another at all is just
> > asking for it. It's a code smell, and it should be avoided.
> >
> > - Jonathan M Davis
>
> That's a not unreasonable argument for not specifying the order of
> evaluation.  But that's irrelevant since D has defined the order so not
> following it is a bug that must be fixed.

Oh, since the spec says that the order is defined, if the implementation
doesn't follow it, it should definitely be fixed. I definitely won't argue
that. But just the same, any code that relies on it is just begging for
trouble and is bad code IMHO.

Though honestly, I expect that it's a bit of a nightmare on the
implementation end of things to keep the order of evaluation correct when
you start lowering one construct to another. That's no excuse. The spec
needs to either be followed or changed, but it doesn't surprise me if such
bugs exist.

- Jonathan M Davis