assignment: left-to-right or right-to-left evaluation?

[Jason House]

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[5];
> >> 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
> http://michelf.com/
>