--- Comment #11 from BCS <>  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

> > 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:
------- You are receiving this mail because: -------

Reply via email to