Dave Handley skrev:
Vicente Botet wrote:
----- Original Message ----- From: "Thorsten Ottosen" <thorsten.ottosen@dezide.com> To: <boost@lists.boost.org> 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