Re: [boost] [AFIO] Review (or lack of it)

Subject: Re: [boost] [AFIO] Review (or lack of it)
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2015-08-28 03:56:30

Niall Douglas <s_sourceforge <at> nedprod.com> writes:

> On 27 Aug 2015 at 12:54, Roland Bock wrote:

> > c) There are older versions in there. There is 1.3 and 1.4 at least (are
> > there more?). Please choose one. Go for it.
> 
> AFIO provides strong ABI and API evolution guarantees. It guarantees 
> that if you compile and link to v2 of the ABI, your code will 
> continue to compile and link no matter what changes next in AFIO.

I think we all very much appreciate backwards compatibility guarantees (and
indeed the lack of this in almost all C++ libraries, Boost included, can be
quite annoying), but of course they do imply added size and complexity.  My
understanding is that AFIO, being a new library, doesn't have any existing
users (except perhaps some of your own unpublished code, but that doesn't
make for a very compelling justification) and therefore there is no benefit
in providing backwards compatibility with prior versions of AFIO.

It seems what you are trying to do is provide a demonstration of the way
backwards compatibility will work for future versions of AFIO, when it would
actually be useful, and also perhaps to provide an example of a good design
for supporting backwards compatibility in C++ libraries.  While this is
interesting, perhaps it would be better to do this as an example separate
from AFIO, so that AFIO can remain as small and simple as possible.

One comment on this design: it seems that different version of AFIO will
function as completely independent libraries, that can each be used
independently.  While this is certainly much better than what most C++
libraries provide, there is still the potential for AFIO version
incompatibilities: one piece of code (A) may rely on version X of AFIO but
also needs to interoperate (via AFIO types) with another piece of code (B)
that formerly relied on AFIO version X, but upgraded to AFIO version X+1. 
Ideally the backwards/forwards compatibility would be finer-grained, so that
this interoperability might be possible, but of course that tends to
severely constrain the types of changes you can make.

> [snip]