[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 #11 from BCS <shro8822 at vandals.uidaho.edu>  2009-07-30 10:59:32 PDT ---

(In reply to comment #10)
> (In reply to comment #8)
> > 
> > This assumes that the body of x is available for analysis and is simple 
> > enough to be analysed. 
> 
> Oh my, I made it sound like the body of the thing would be analysed.  Poor
> wording.
> 
> No that's not the case, I was mostly just referring to the declaration.  
> 
> The only thing that matters there is that it looks at foo's return type, finds
> an rvalue, and thinks "hmmm, that might mess up someone's day."
> 
> My point was that it doesn't matter whether it looks at the noop version or 
> the non-noop version, either way it finds the same rvalue in the return and 
> decides to the negative.
> 

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.

> > Any implementation that doesn't give the same functionality as .di files
> > (no-source symbol decelerations) effectively eliminates the ability to have
> > closed source D libraries. Therefor, the feature causing problems 
> > effectively is part of the spec.
> 
> .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.

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