[cfe-dev] on libc++ extensions and slist

[Jonathan Sauer]

Hello,

> [...]
> 
> Possible solutions to ease migration and not lead our customers into horrible mistakes we already know about:
> 
> 1.  We could create an ext::slist that lacks size().  That way the customer would not have to change their code unless they used size().
> 
> Disadvantage:  We haven't delivered a seamless drop in replacement lib.  They still have to change their code.  Why not also change the name of the container to std::forward_list at the same time?  Otherwise we have to support slist.  And not just to ease migration.  Once we introduce it, we have to support it for forever for backward compatibility with our own lib.

At least until a new version of libc++ comes along. As far as I see, then backward compatibility can be broken.
Of course, this just postpones the migration efforts discussed below ...

> 2.  Status quo:  We could do nothing.
> 
> Disadvantage:  I'm seeing rising complaints about migration efforts.
> 
> 3.  Educate:  In a private email about a week ago M.E. O'Neill noted that we should provide documentation recommending migration strategies for things like slist -> forward_list.  She suggested actually providing an <slist> header which did nothing but point to the documentation and then error out.  I'm not sure I'd go as far as providing such a header.  But I am really enthusiastic about a "migration document".  Having something to point to which explains why using slist is like playing with a loaded gun.  When people are migrating, they are open to such arguments if those arguments are both convincing and readily available.  And if the migration document provides a way to experiment without committing yourself (i.e. make it easy to backpedal the migration):

I'm in favour of such a header. *Providing* documentation is only one part of the equation; the documentation also
has to be found. An #error in the slist header containing the URL of the migration document would simplify this.

> Disadvantage:  Doesn't provide seamless migration.  And it is a fair amount of work to document.

But is seamless migration actually a reasonable expectation for someone changing from libX to libc++? After all,
slist has always been an extension, so despite the fact that many standard libraries implement it, one has to expect
to have to change code when moving to libc++.

A second point: People will most likely not migrate to libc++ just for fun. They will migrate to it e.g. because
they want to have a C++0x conforming standard library, and because the standard library they are currently using
does not provide this (e.g. because development on it has ceased, or because newer versions come with an imcompatible
license). And since C++0x has a single-linked list implementation, there is no need anymore to use slist (the same
goes for hash_map et.al).

> Field experience:  I'm responsible for deprecating auto_ptr.

One of the best changes in the C++0x standard library :-)

> [...]

Jonathan