http://d.puremagic.com/issues/show_bug.cgi?id=6495



--- Comment #10 from monarchdodra@gmail.com 2013-08-01 11:16:36 PDT ---
(In reply to comment #9)
> Taking the address of .front technically undefined,
> since you can't guarantee that that's even possible for arbitrary range types
> (in general, it's not possible, since .front may be implemented as a @property
> function). If .front were a ref function, then you may have a point.

That's BS. That's like saying indexing is undefined because an arbitrary range isn't indexable. We have the `hasLValueElements` trait specifically for this. Ranges that offer references to their internal exist, and are a class of their own. Also, the "@property" thing is a non-argument: It is just buggy behaviour; The new implementation (as explained by Kenji) is that &propFun should and *will* return the address of what is returned after having called propFun.

That said, I'll *agree* that there is not a single trait that guarantees references remain valid after a pop, nor does *anybody* rely on it, so we can indeed safely say that my point was, well, pointless :)

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