[Gavin Lambert]
I suspect though that if it's not removed at some point, then people will continue using it incorrectly; this was probably a factor in the committee's decision to remove it rather than merely leaving it deprecated, and similarly for MS following suit.
Yes. Regardless of how individual Boost developers may feel about the issue: 1. auto_ptr/etc. have been removed from the C++17 Working Paper. It's done, they're gone, and they're not coming back. (They were deprecated in C++11/14, so National Bodies can't object - that is the very meaning of deprecation.) 2. Implementations are migrating - GCC is emitting deprecation warnings, and VC is moving towards outright removal. 3. On the other side, Boost should respect the wishes of programmer-users who wish to migrate early (e.g. compiling with /D_HAS_AUTO_PTR_ETC=0). Therefore, Boost should stop using auto_ptr/etc. The mechanism for doing so is up to you (conditioning on toolset version is probably the way to go, possibly with escape hatches). Supporting leading-edge toolsets in this manner should be no different than supporting the old toolsets that Boost already goes to great effort for. Stephan T. Lavavej Senior Developer - Visual C++ Libraries