[Issue 3008] Members of non-lvalues (rvalues) can be assigned to.

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3008





--- Comment #14 from BCS <shro8822 at 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: -------