new concept checks and the 3.0 ABI

[Joe Buck]

Jason Merrill <jason_merrill@redhat.com> writes:
> | What I think Joe is asking about is the libstdc++ ABI; in other words,
> | should people be able to expect that STL-using code compiled with 3.0 will
> | link with code compiled with 3.1?  In other words, should we commit
> | ourselves to making only representation-compatible changes?  Mark has
> | expressed the opinion that we should.  I'm ambivalent.

Exactly.

Gaby writes:
> That is a very strong requirement I would like us not committed to.

Without such a requirement, claiming that the C++ ABI is stable is a joke,
and we should just drop the claim.

GCC team: "The C++ ABI is stable".

User: "OK, why doesn't my 3.1 code link against my 3.0 code?"

GCC team: "You used a class that we provided you, and we changed it."

User: "But I downloaded that class library as part of GNU C++."

GCC team: "Yes, but we thought of a new way to do concept checks, and
           added some cool new refactoring".

User: "But you said the C++ ABI is stable."

GCC team: "But only for the compiler, not the library."

User: "But how can I write C++ without a library?"

So, Gaby, do you want us to tell the users that, if they want to ship
libraries that don't have to be recompiled each and every time we ship
a new compiler, they have to avoid all use of libstdc++?

Now, I do see your point -- it can be argued that we just aren't ready.
libstdc++-v3 still isn't stable enough to have its ABI frozen; we haven't
really taken advantage of factoring to reduce bloat from the STL (e.g.
using the same code for vector<T> for T's that are POD's, and having that
code in the library), and we don't really know if we're doing everything
the best way.

Maybe we'll have to aim for compiler ABI freeze in 3.0, library in 3.1
(in the sense of glibc: changes are backward compatible).  But we do need
to think about how to achieve a library ABI freeze.