<div class="gmail_quote">On Sat, Jul 30, 2011 at 18:31, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<snip><br>
<br>
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().<br>
<br>
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.<br>

</blockquote><div><br>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.<br>

<br>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).<br>

<br>Thoughts?<br><br>Sean<br></div></div>