Re: [boost] [range] [general] making member functions SFINAE-friendly

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?

-Thorsten