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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk