On 12/24/2013 01:48 AM, H. S. Teoh wrote:
Agreed. Note that introducing assignment into the mix may not help
matters, but complicate them even more. For example:
int x=1, y=0;
writeln((y = ++x) + (++y--) * (x=y)); // what does this print?
...
'y-- is not an lvalue'.
Assuming we add parens as follows:
int x=1, y=0;
writeln((y = ++x) + ((++y)--) * (x=y));
We should get 8 according to strict left to right evaluation rules.
Furthermore, we should have the value 2 stored in both x and y.
Or worse yet:
int func1(int x) { ... }
int func2(int x) { ... }
int func3(int x) { ... }
int function(int)[] funcptrs = [ &func1, &func2, &func3 ];
int x=0, y=0;
y += funcptrs[++x--](y = --x++); // what does this do?
'x-- is not an lvalue'
'x++ is not an lvalue'
Assuming we run the following code instead:
int func1(int x) { return 1*x; }
int func2(int x) { return 2*x; }
int func3(int x) { return 3*x; }
int function(int)[] funcptrs = [ &func1, &func2, &func3 ];
int x=0, y=0;
y += funcptrs[(++x)--](y = (--x)++)
We should be left in a state where x contains 0 and y contains -2
according to strict left to right evaluation rules.
The only place I can see where you'd even*want* to write code like this
is in an entry to the IOCCC. Make it refuse to compile, I say.
I don't think it makes sense to add some arbitrary rules to the compiler
implementation just to ban some code that nobody writes anyway and
potentially some perfectly fine code as well.
