Re: [boost] [range] Should ranges really propagate constess to the data ?

Subject: Re: [boost] [range] Should ranges really propagate constess to the data ?
From: Neil Groves (neil_at_[hidden])
Date: 2011-07-24 09:41:48

>
> >> <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