I did mention that, "no one suggests that shared_ptr should (or could) be changed in ways that impacts backwards compatibility." What I /am/ considering is if there is a way to make the shared_ptr implement the null object paradigm, but only for a particular user type T, but otherwise not impact current behavior of shared_ptr including revealing in its public interface all that is good and bad with the nill state of raw pointers. In the example above type ChessPiece might enforce the null object pattern for shared_ptr but user types that don't specialize the null object factory class would retain exactly current behavior. Thanks for the reference, I will definitely have a close look. Jeff -- View this message in context: http://boost.2283326.n4.nabble.com/Why-no-non-null-smart-pointers-tp2642959p... Sent from the Boost - Dev mailing list archive at Nabble.com.