[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 #13 from Chad Joan <chadjoan at gmail.com>  2009-07-30 12:46:33 PDT ---
(In reply to comment #11)
> 
> OK then that's another (potentially worse) problem because I can think of
> several cases where I want to return a struct (by value) and invoke functions
> on it. Based on your rule, I'd always have to store it in a local to do that. I
> don't see that flying.
> 
> The only cases I can see being banned is member variable assignment on a struct
> return.
> 

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)
}

So yes, getting rid of the former is a step in the right direction.
That latter is still quite undesirable.

> > 
> > .di files and bodyless function declarations, these are two different things. 
> 
> 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------