Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]

Subject: Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2014-03-25 16:50:47

On Mar 24, 2014, at 10:36 AM, Marshall Clow <mclow.lists_at_[hidden]> wrote:

> 
> On Mar 24, 2014, at 2:14 AM, Valentin Ziegler <vziegler_at_[hidden]> wrote:
> 
>> Hi Adam,
>> 
>>> 1. front()
>>> returning the reference to the first element precondition (assert): !empty(rng)
>> 
>>> return *begin(rng);
>> 
>>> 2. back()
>>> returning the reference to the last element precondition (assert): !empty(rng)
>> 
>>> For BidirectionalRange
>>> return *(--end(rng));
>> 
>> In 99% of all cases above implementations will work just fine. However, there may be rare cases where the lifetime of the reference is bound to the lifetime of the iterator:
>> 
>> [iterator.requirements.general] 9. Destruction of an iterator may invalidate pointers and references previously obtained from that iterator.
> 
> Interesting. I think that in C++14, the committee put that possibility to bed.
> See LWG issue 2360 http://cplusplus.github.io/LWG/lwg-defects.html#2360
> 
> I’ll open an issue that gets that cleared up.

Thinking about this some more, I think that “may” is the key there.

[forward.iterators] says:
        • 6  If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object.

which disallows “stashing iterators” for forward (or greater) iterators.

So, I think that [iterator.requirements.general] 9 can only really be true for input iterators.

— Marshall