[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 #9 from Chad Joan <chadjoan at gmail.com>  2009-07-30 10:38:44 PDT ---
(In reply to comment #7)
> (In reply to comment #5)
> 
> > Of course, s2.foo().x(5) violates the principle at play here.  At this point,
> > the whole "version(noop)" thing is just fluff, and here is the meat of the
> > matter.  In this example, "s2.foo.x = 5;" does actually do something and is
> > reasonable code.  However, naively forbidding an rvalue on the lhs of an assign
> > expression will make that code fail to compile.  I don't feel that code like
> > this is terribly common or that much better than the alternatives, so it is
> > probably worth losing some corner cases like these for the sake of preventing
> > nasty bugs.  
> 
> You are killing the entire feature of making user-defined "builtin" types, such
> as a custom pointer type.  Since those would undoubtedly be structs, and
> therefore returned as rvalues, you could not use them for anything without
> first creating lvalues out of them.  If we are to have such constructs, they
> should be on par with native pointers.  At the very least, we should have a way
> to mark such structs as "allow rvalue operations."  I would be ok with that.

You make it sound like we wouldn't be able to use structs anymore!

Not the case.  

struct S
{
  int _x;
  version(noop)
    void x(int n) { _x = n;}
  else
    void x(int n) { _global = n;}
}

struct S2
{
  S foo() { return S(5);}
}

void main()
{
    S2 s2;

    s2.foo.x = 5; // not good.

    int bar = s2.foo.x + 42; // fine, rvalue is not mutated, only read.

    auto s = s2.foo;
    s.x = 5; // fine

    S s1;
    s1.x = 5; // fine
    s1._x; // fine, it was declared public.
}

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