On Tue, Apr 09, 2013 at 09:59:42PM -0400, Steven Schveighoffer wrote: > On Tue, 09 Apr 2013 19:31:59 -0400, H. S. Teoh > <hst...@quickfur.ath.cx> wrote: > > >On Tue, Apr 09, 2013 at 07:18:25PM -0400, Steven Schveighoffer wrote: > >>On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling > >><joseph.wakel...@webdrake.net> wrote: > >> > >>>On 04/10/2013 12:50 AM, Joseph Rushton Wakeling wrote: > >>>>I did consider something like that. > >>> > >>>By the way: the reason that I rejected the temporary-variable > >>>choice was that I couldn't really see the difference cost-wise > >>>between doing that, versus returning var.dup from front(). > >>>Especially as it's not necessarily guaranteed that front will be > >>>called frequently (I might just popFront() until the range is empty > >>>and then take the final front value). > >> > >>Calling front after empty is not good range policy, once empty, > >>front is possibly invalid or points at invalid memory. > >[...] > > > >I believe it was proposed that .front should assert if .empty returns > >true. Personally I think that's a bit too extreme, but nevertheleses, > >I agree that calling .front after .empty returns true is sloppy > >coding, and can easily lead to bugs or runtime errors. > > That is not necessary. A range does not just have to be a range, it > just has to support a range interface. > > It can be perfectly valid for front to not assert. It can be also > valid for it to assert. It just means that functions that generically > operate on ranges cannot count on front working after empty is true > (and that WOULD be a bug). [...]
Yes, that was my point. I didn't mean to say that front *should* assert, just that it *might* for some ranges. (In fact, I've written my own ranges that do support calling .front even when .empty is true.) In generic code, though, one should not assume one way or another. T -- Study gravitation, it's a field with a lot of potential.