<snip>
Well, if we want something like std::vector to be a Range, then we have to accept that at least *some* Ranges do propagate constness. And I'm pretty sure that we don't want other Ranges (std::pair<char*,char*>) to propagate constness. So unless the documentation says otherwise, I would assume that the concept doesn't say anything about whether constness is propagated. If you want to write generic Range code you have to account for both cases.
Constness is propagated for containers, yes, but sub_range is not a container, it is a view of another range, so it should propagate the constness.
[Just to avoid confusion.]
...so it should *not* propagate the constness. Yes, I agree, but that was explicitly the interface decision and luckily there's usually a workaround (use boost::iterator_range).
I am currently considering the possible changes we could make to sub_range. Ultimately sub_range is implemented as the original author intended. If one specified the range using a template parameter that is a Range type one must determine which of the mutable of const iterator types to use in the underlying iterator_range. Fundamentally the iterator_range class makes you decide by providing the iterator type, whereas the sub_range allows you to specify the Range type and then provides multiple overloaded implementations of begin/end that extract the appropriate types via the range_iterator meta-function. How do you imagine the const / mutable underlying iterator would be chosen? If you are proposing that the const-ness of the sub_range template parameter is used, I think that this would break to much existing code. The current semantics have been in place since at least version 1.33. I do agree that sub_range's behaviour is rarely required or desirable. My approach has been to use iterator_range for most of my code. I imagine that you would prefer a class similar to iterator_range differing in so much as it takes a Range or const Range as the template parameter. I'll give this some more thought. I would like to avoid the proliferation of similar classes, and breaking interface changes, but I am motivated to provide a solution for your use case.
- Jeff
Regards, Neil Groves