Range returning an array

[Steven Schveighoffer]

On Tue, 09 Apr 2013 19:31:59 -0400, H. S. Teoh <hsteoh at 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.wakeling at 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).

For example, if the OP replaced his range with someone else's, he may run  
into that situation.  But as long as he is the author, it is not illegal  
for an object that is also a range to be empty and have front still work.

-Steve