-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dave Handley
Personally, reading this entire thread, I find the proposal by both Tomas Puverle and David Abrahams that 2 versions of iterator_range exist, one that tests for singularity and one that doesn't, by far the most palatable solution. It allows you to have a lean and mean iterator_range if you want
to store lots of them in a container (the use case that Dave talks about),
it also allows you to have an empty range when you need an iterator_range to look like a container. This could be trivially implemented with inheritance or a policy template. It would be a nice solution to the problem from both
directions, and I think it makes the most sense.
Dave
Thinking of two versions, another point to consider is the existence of sub_range. Whilst I can see that it seems fairly natural for iterator_range<iterator_t> to have iterator-like behaviour, what about when it is phrased as sub_range<container_t> ? At the moment this is also iterator-like but if you were working from intuition rather than from docs, users could also easily guess it is container-like.