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

[Sean Hunt]

On Sat, Jul 30, 2011 at 18:31, Howard Hinnant <hhinnant at apple.com> wrote:

> <snip>
>
> 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.
>

Size is not the only issue with slist. Slist also features container
operations without the _after suffix, meaning they operate on the elements
pointed to by the iterators. These, also, must have linear complexity, and
so don't exist in forward_list. Given this, the migration may be far from
trivial - especially given that clients might find that they really ought to
be using a doubly-linked list (or some other container) in their situation.

One idea that I had for an unrelated problem but might be useful for this
one as well would be to have specific deprecated tags like
[[deprecated(forward_string)]]. We could put these on the functions that are
removed from the standard library, and migration could be done one container
at a time by turning on each deprecated tag in order (something akin to
-Wdeprecated=forward_string). We could put this on the slist functions that
are not present in forward_list, and thus someone can clean up their
codebase until it should be a drop-in replacement, and then perform the
drop-in replacement. (N.B. to Chandler: I'm aware that this is not
applicable in our situation).

Thoughts?

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110731/9859e059/attachment.html>