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

Subject: Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-03-23 17:33:36

Hi,

Neil Groves wrote:
> iterator_range already has front() and back() functions. These are not part
> of the Range Concept since we want to be able to model them
> non-intrusively. The iterator_range and sub_range classes can be used to
> wrap other iterator pairs or ranges and provide most of the member
> functions that you are suggesting.

Thanks for the tip. However I rather see those functions as algorithms, 
not a part of the Concept. They musn't be modeled intrusively, just like 
any other Boost.Range algorithm.

So in the case of iterator_range the use case would look like this:

boost::make_iterator_range(range).front();
boost::make_iterator_range(range).back();
boost::make_iterator_range(range)[index];

I'd say it's less intuitive/readable/convenient than:

boost::front(range);
boost::back(range);
boost::at(range);

And the readability is what I wanted to achieve but ok, the 
functionality is there. And this way the implementation of operator[] is 
straightforward. Still, I prefer my way :)

Regards,
Adam