> I see portability as the main goal with SD-6: If a newer feature
> is not
> available on one of your target platform/compiler combinations you
> have
> to roll back to the older facility. Different compilers are at
> different places toward full feature support.

Of course; but N4190 doesn't add a new feature, it removes features. It's a completely different sort of problem, one that we really haven't explored
before.

> > The question is, once someone writes code that uses a new/better
> > facility in place of a deprecated/removed facility, would they
> > really want or need to keep around the code that uses the
> removed
> > facility? How would they benefit by doing so?

> Portability - across compilers and even within a compiler across
> C++ versions.

Your gave a very general answer to a question I intended to be pretty
specific. Let me make it even more specific.

Someone has some code that uses auto_ptr. He changes it to use unique_ptr.
He might benefit by keeping around the old code, for portability to an implementation that doesn't provide unique_ptr. But he will benefit only if
there's a feature-test macro that tells him that he can use unique_ptr. A
macro that tells him that he can't use auto_ptr doesn't seem like it would
be useful. If he is willing to assume (or simply hope) that unique_ptr is
available everywhere, then he simply has no reason to keep around the code
that uses auto_ptr, whether it's available or not.

Clark