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?
}
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/
