http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #11 from BCS <[email protected]> 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: -------
