Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-11-23 07:36:23

Tomas Puverle skrev:
> You may or may not have noticed a thread I started on boost.users about the
> breaking changes to Boost.Range.   Here’s a short summary:  We are currently
> (firmwide) using boost 1.33.1.  I am in the process of trying to migrate and
> test some of our apps with boost 1.37.  In 1.35 there was a breaking change to
> Boost.Range with respect to how singular ranges behave.  This brings up several
> issues:
> 
> 1)	The breakage was silent.  The interface stayed the same but the behavior
> changed, and drastically so.

But clealy any test would not fail silently if it was run in debug mode. 
You would get an assertion in your code.

Let my just say that your code example was legal in the sense it used a 
documented behavior of Boost.Range which I had chosen to change. 
However, It was not legal generic code in the sense that you could not
parse any range to function:

template<class Range>
void foo(const Range & r_)
{
   if (r_.empty()) {...}
}

You'd had to write it like this:

template<class Range>
void foo(const Range & r_)
{
   if (boost::empty(r)) {...}
}

> 2)	No communation:  While I don’t usually post to boost.devel/boost.user, I and
> my colleagues still read it.  Nobody recalls any mention of this on the list. 
> Searching gmane brings up nothing, either.
> 3)	No documentation on the boost website.  As far as I can see, this change was
> introduced in 1.35 this March.  
> On http://www.boost.org/users/news/version_1_35_0, there is no mention of a
> breaking change to Boost.Range.

That is of course my fault, that I didn't used more of my spare time to 
document this properly. The initial design was not optimal, and I 
prioritzed fixing it higher than documenting the changes.

> 4)	The new Boost.Range behaves differently in debug and release builds.  The
> public function is_singular() always returns false in release builds even when
> it would return true in debug builds.

IIRC, this is not a documented function, and hence you cannot expect it 
to be there in the next release etc.

> Apart from the fact that this change breaks a lot of our code and obsoletes
> several useful (necessary?) idioms, the manner in which it happened is far below
> the standards that one has come to expect from boost.
> 
> At the moment, I have to say I don’t have a good answer to how to fix our code.
>  However, I would at least like to try to make sure this kind of silent breakage

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.

At the end of the day, I think the change was right, but I also 
sympathesize with the view of stability. It would be a good thing if we 
could improve the communication between end-users and developers, and 
find guidelines that allow libraries to move forward, while not breaking
too much code silently/unintentionally.

best regards

-Thorsten