On Sun, Jul 24, 2011 at 6:41 AM, Neil Groves <neil@grovescomputing.com>wrote: [...]
I am currently considering the possible changes we could make to sub_range. Ultimately sub_range is implemented as the original author intended.
As I had inferred, given how the documentation explicitly mentions the propagation of const'ness. [...]
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.
That's a legitimate concern.
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.
I'm not sure what to do either, but I'm not opposed to "do nothing" :/ Maybe add some rationale for why sub_range propagates const'ness. - Jeff