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:
> I'd say it's less intuitive/readable/convenient than:
> 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.