Michel Fortin Wrote: > On 2009-05-11 05:49:01 -0400, Georg Wrede <[email protected]> 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 > [email protected] > http://michelf.com/ >
