[cfe-dev] Proposal: Managing ABI changes in libc++

[Eric Fiselier]

I don't really like allowing users to pick and choose which ABI
changes to adopt. I personally don't see the use case for picking a
subset of ABI changes to adopt. If you can adopt one ABI change,
then why can't you adopt them all? Furthermore, as time goes on and
more ABI changes are commited this could lead to quite a mess.

I also don't like having a stable version and an unstable version of
the ABI. I'm afraid that by only introducing ABI changes into the
"unstable ABI configuration" they will never be adopted.

Instead I think we should version the ABI and introduce a series of
stable ABI's under different versions. This allows us some sort of
forward momentum and fewer configurations that need maintaining and
testing.
When a consumer can tolerate introducing an ABI break they can move to
the most recent ABI version. After a given amount of time ABI versions
would be deprecated.
The only ABI versions that would be maintained indefinitely would be
the current one.

/Eric


On Mon, Dec 8, 2014 at 11:20 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
>
>> On Dec 8, 2014, at 9:57 AM, Nick Kledzik <kledzik at apple.com> wrote:
>>
>> Marshall,
>>
>> I'm glad you are thinking about this and working through a design!
>>
>> Have you considered using mangling to keep ABI changes separate?  That is, mangle the class or namespace differently (perhaps __2 instead of __1) for new ABIs.   That way no one case accidentally link two different ABIs.
>
> Nick —
>
> I’ve done some thinking along those lines, but that seems like a very bit hammer for these kinds of changes.
>
> I’ll puzzle some more.
>
> — Marshall
>