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

Subject: Re: [boost] [range] Proposal: addition of front(), back(), at(), operator[]
From: Neil Groves (neil_at_[hidden])
Date: 2014-03-23 21:21:22

>
> 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 :)
>
>
Yes, I agree with your comment. I wanted to demonstrate that the
functionality existed in currently released versions. I have been planning
to add support for non-member front and back functions in addition to
drop_front and drop_back functions. With these and a few other additions we
will be able to model range primitives while interoperating with existing
iterator-based ranges. I was hoping to get my trac tickets in good shape so
that 1.56 is nice and stable before adding these new features for 1.57.

>
> Regards,
> Adam
>

Regards,
Neil Groves