http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #9 from Chad Joan <chadj...@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: -------