Re: [boost] [1.36.0] Libraries with unmerged changes?

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-16 17:18:50

on Wed Jul 16 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

>>>> Also, avoiding all interface breakage may restrict a developer's
>>>> flexibility more than you imagine.  Consider:
>>>
>>>> * Adding an optional argument to a function or an optional class
>>>>   template argument, which should be a non-breaking change for most
>>>>   everybody, can break user code.
>>>
>>>> * Adding an overload can break user code.
>>>
>>>> * Adding a new name to a namespace can break user code.
>>>
>>> I"m sure I could do all of these things.
>>
>> I'm not sure what you mean.
>
> What I mean is that I could easily do all these things unintentionally
>
>>> Generally I would consider it a bug.
>
> In my code.
>
>> In your code or the user's?  If yours, are you seriously willing to
>> say you won't introduce any new functions or types into an existing
>> namespace?
>
>>From time to time I would expect the library to be extended
> by adding new functions and perhaps new types into an existing
> namespace.  It has never occurred to me to that this could
> break user code - but now that you mention it I suppose it could
> if users had added their own stuff to the archive namespace.  

That is normally a no-no.  However

     using namespace boost::archive;
     struct foo {};
     
if boost::archive acquires a "foo" there will be ambiguity.

> However,
> I would probably consider this a user error in that it violates
> the intention of name spaces to avoid just this problem.

Yep.

>> So if it began to cost you something, you'd drop support even though
>> it would be a breaking change for some users?
>
> And of course, that would be OK. Even in this case I might want to
> leave around the old version.  But, I guess that my pledge would have
> to extended to cover this case.  On the other hand, the "pledge" is
> mostly a retorical device to make a point so I'd rather not turn it
> into the tax code.

Well, my point was precisely that if you aren't strict about what it
really means, everyone will take the pledge whether they intend to meet
*your* standards of stability or not.  You're the one who brought up
mathematical provability.  If you don't nail down the meaning of this
pledge, so you can prove (to yourself and others) that you have not
violated it, it becomes effectively meaningless.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com