http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #14 from BCS <shro8...@vandals.uidaho.edu> 2009-07-30 13:02:20 PDT --- (In reply to comment #13) > That'd be a start. > > The problem then is that variable assignment is equivalent to function calls > with 1 parameter due to the omitable parentheses rule. > > Thus if we banned member variable assignment on struct returns, this happens: > > struct Foo > { > int x; > int y(int val) { return x = val; } > } > > Foo foo() > { > Foo f; > return f; > } > > void main() > { > foo.x = 5; // compile error, member assignment on returned struct > foo.y = 5; // compiles just fine, function invoked on returned struct > // (but is a bug waiting to happen) > } While I can see where you are coming from, I have no problem at all with that. > > > > Well, as I pointed out, one or the other is needed so, either way, there > > side > > effect have to be dealt with. > > Why does it matter for rvalues though? We aren't analysing the function > body, > just the declaration, and that's something the compiler has to do anyways to > ensure type safety. See above. Without analyzing the function bodies, Applying all this to functions will also ban things I'm not willing to give up. As an example: should this be alowed: struct S { void M(int arg) { ... } ... } S fn() { ... } fn().M = 5; how about (the equivalent): fn().M(5); how about if I rename it: struct OutputHandle { void Output(int arg) { ... } ... } OutputHandle GetProcessOutput() { ... } GetProcessOutput().Output(5); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------