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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Jul 28 18:09:13 PDT 2009


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


Jarrett Billingsley <jarrett.billingsley at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley at gmail.c
                   |                            |om




--- Comment #3 from Jarrett Billingsley <jarrett.billingsley at gmail.com>  2009-07-28 18:09:12 PDT ---
(In reply to comment #2)
> Consider this actually sensical case:
> 
> struct S
> {
>   int *a;
> }
> 
> S foo() {...}
> 
> *foo.a = 3;
> 
> Clearly, you don't want structs to be non-modifyiable in all cases.  If S has
> member functions which modify both values of S and values S references, then
> you should able to call those functions also.  It might be very difficult for
> the compiler to distinguish all these cases.

Actually the compiler wouldn't have to do anything special here.  If the return
of foo() were an rvalue, then *foo().a could still be an lvalue, not because of
any special rules, but because of how the dereference operator works.

A more thorough explanation: DMD will diagnose no-op statements such as:

x + y;

Since such code is dead and possibly a typo (say you accidentally shifted your
assignment operator there).  Code like:

struct S { int a; }
S foo() { return S(5); }
foo().a++;

Should be nonsensical for the same reason.  foo() is an rvalue, and
rvalue.field yields an rvalue.  Similarly, in your example, "foo().a = new
int;" would be nonsensical, since again, rvalue.field yields an rvalue.  But as
soon as you use the dereference operator, foo().a becomes an lvalue.  (In fact
I think K&R describe * and & in such terms (turning lvalues into rvalues and
vice versa).)

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


More information about the Digitalmars-d-bugs mailing list