--- Comment #7 from Steven Schveighoffer <>  2009-07-30 
07:19:24 PDT ---
(In reply to comment #5)

> Of course, 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, " = 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.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to