Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-11-24 06:57:32

Dave Handley skrev:
> Vicente Botet wrote:
> 
>> ----- Original Message ----- From: "Thorsten Ottosen" 
>> <thorsten.ottosen_at_[hidden]>
>> To: <boost_at_[hidden]>
>> Sent: Sunday, November 23, 2008 11:50 PM
>> Subject: Re: [boost] Breaking existing libraries
>>
>>
>>>
>>> Dave Handley skrev:
>>>>>
>>>>> I have looked it up, and its not documented. Period.
>>>>>
>>>>> Anyway, I'm sorry you feel the way you do. I don't intentionally try
>>>>> to break people's code, and I have put an enourmous effort into the
>>>>> code I've submitted to boost.
>>>>>
>>>>> FWIW, boost.range is not changing anymore.
>>>>
>>>> Unfortunately, you've already broken my confidence - unless of course,
>>>> we can come up with a decent compromise on this which seems further 
>>>> away
>>>> by the hour.
>>>
>>> If the compromise does not include going back to the old behavior for
>>> boost::iterator_range, then I'm open to suggestions (If we did that, how
>>> would we explain that situation to all those that want the current
>>> behavior?).
>>
>> Some one has already proposed boost::old_iterator_range and if I 
>> remember well you have proposed boost::deprecated::iterator_range.
>>
>> "I guess The old behavior could be supplied in
>> <boost/range/deprecated/iterator_range.hpp> in namespace
>> boost::deprecated. Again, it is a matter of time."
>>
>> Is this a good compromise for all?
>>
> 
> Not really - as a library user you can't rely on deprecated 
> functionality. If my code was broken by this change, and the change was 
> reverted in a deprecated version, I would probably just drop the library 
> out of the (valid?) fear that the deprecated interface would be dropped 
> at some point.
> 
> The proposal that has been made multiple times in the other thread is 
> that both types of functionality are valid, and that there should just 
> be 2 classes.  One could easily be made to inherit off the other, both 
> would be useful for different use cases.  As far as I can tell, no-one 
> has made a solid critique against that proposal, but on the other hand, 
> there still doesn't appear to be a consensus.

I'm fine with having a non-deprecated boost::range<T> with the old 
behavior. I don't know if there is concensus for this?

Let me just comment on the critiue there has been of the new concepts. 
The concepts where changed after lengthy discussions here on this list, 
initiated by real problems in using Boost.Range other parts of boost.
I think it is fair to say that the new concepts are also much cleaner 
and minimal, and hence puts lets burden on the user.

The docs should also have a "Upgrading from 1.32" section. As to whether 
  the old concepts should still be documented, then I don't know. The 
old docs are on our website, but I guess we could link directly to them.

As for time, then it is a problem currently. But I guess 1.38 is some 
time away anyway.

-Thorsten