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:25:04

On Sat, Jul 23, 2011 at 4:13 PM, Dave Abrahams <dave_at_[hidden]> wrote:

>
> on Fri Jul 22 2011, Samuel Debionne <debionne-AT-hydrowide.com> wrote:
>
> > Hello everyone,
> > Here is an example code that motivates my question :
>
> <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.
>
>
Currently the Range Concepts are not documented as propagating const-ness,
but the sub_range class has been documented as propagating const-ness since
at least Boost 1.33. The implementation uses boost::range_iterator<T>::type
or boost::range_iterator<const T>::type as the return type for begin() and
begin() const respectively. This means that sub_range supports all models of
the Range Concept and behaves as intend for both examples you cited
(std::pair<char*,char* and std::vector). My understanding of the original
design is that it is one of the central purposes of the sub_range class.

It seems that there is a desire to have some syntactic sugar when defining
the iterator_range type, but we must select the const or mutable version of
the iterator and hence it isn't immediately obvious how one would implement
this in a manner that is more elegant than simply using iterator_range.

My current belief is that the sub_range class does what was intended
correctly, but it has quite limited usefulness. Changing the const-ness
propagation of sub_range would be a nasty interface breakage and make the
sub_range a very questionable abstraction since one would have to chose the
const or mutable version of the Range iterator by an explicit means making
it almost indistinguishable from iterator_range. There are a number of
possible actions I can take. I could leave the code as it is and improve the
documentation of sub_range. I could, if the confusion merits it, deprecate
sub_range.

I am very interested in feedback about the potential design decisions. I am
particularly interested in alternative solutions that I have not considered.

> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
>
>
Regards,
Neil Groves