assignment: left-to-right or right-to-left evaluation?
jason.james.house at gmail.com
Mon May 11 05:48:16 PDT 2009
Michel Fortin Wrote:
> On 2009-05-11 05:49:01 -0400, Georg Wrede <georg.wrede at iki.fi> said:
> > Andrei Alexandrescu wrote:
> >> Consider:
> >> uint fun();
> >> int gun();
> >> ...
> >> int a = new int;
> >> a[fun] = gun;
> >> Which should be evaluated first, fun() or gun()?
> > arra[i] = arrb[i++];
> > arra[i++] = arrb[i];
> > I'm not sure that such dependences are good code.
> > By stating a definite order between lvalue and rvalue, you would
> > actually encourage this kind of code.
> Well, I agree with you that we shouldn't encourage this kind of code.
> But leaving it undefined (as in C) isn't a good idea because even if it
> discourages people from relying on it, it also makes any well tested
> code potentially buggy when switching compiler.
> You could simply make it an error in the language to avoid that being
> written in the first place. But even then you can't catch all the cases
> statically. For instance, two different pointers or references can
> alias the same value, as in:
> int i;
> func(i, i);
> void func(ref int i, ref int j)
> arra[i++] = arrb[j]; // how can the compiler issue an error for this?
D2 could have no ordering guarantees, and simply give an error when reordering could effect impure operations. Flow analysis could relax this rule a bit. Local primitives that have not escaped are immune to side effects affecting other variables.
> So even if you make it an error for the obvious cases, you still need
> to define the evaluation order for the ones the compiler can't catch.
> And, by the way, I don't think we should make it an error even for the
> so-called obvious cases. Deciding what's obvious and what is not is
> going to complicate the rules more than necessary.
> Michel Fortin
> michel.fortin at michelf.com
More information about the Digitalmars-d