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