Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-02-20 09:57:04
On 20-02-2013 00:11, Neil Groves wrote:
> To me this seems simpler than having more base classes, but comes at the
> cost of eventually breaking backward compatibility.
> I've been very wary to discuss this since I've never managed to convince
> myself sufficiently that this is the optimal solution. I'm extremely
> reluctant to break interfaces, but with a sufficient period for the
> deprecation perhaps the community would prefer this option?
> I have been wrestling with this issue for some time, and think that
> deprecating the member function size() on iterator_range combined with the
> provision of an extensible boost::size(rng) that has O(1) would be a
> reasonable compromise. We have boost::distance already which provides the
> complexity guarantee equivalent of std::distance. If we add
> boost::size(rng) that delegates to range_size then I could provide
> implemetentations for the standard containers, and users could augment the
> behaviour to keep O(1) size for other containers, and could even choose to
> loosen the performance guarantee if they desired.
> I'm very keen to hear the thoughts of current users since I am unsure how
> much code relies upon iterator_range member size() function. Additionally I
> bet Thorston and Nate have some great ideas.
-1 for the idea of introducing another base class.
Breaking the interface could be done, but I guess we would have 2 or
three releases before it actually came into the code? What's the
official Boost policy on this matter? I don't know how much that time
line would help Jonathan's clients or those writing generic code that
accepts an O(n) time size operation.
Having a tool for getting the O(1) size() from containers which
currently fail to work with boost::size() would be good. However, how do
we do that without concept-based overloading?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk