--- Comment #11 from BCS <shro8...@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
> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------