On Sat, Jul 23, 2011 at 4:13 PM, Dave Abrahams <dave@boostpro.com> 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