Andrey Semashev:
Peter Dimov wrote: ...
thread_specific_ptr was more or less intended to provide a C++ equivalent to pthread_setspecific, and the POSIX interface associates a single destructor function to a TSD slot. It's technically possible to emulate shared_ptr, but is there a reason for that?
There is no specific reason for that. That feature would just follow from the interface if thread_specific_ptr was consistent with shared_ptr.
But it's not (semantically) consistent with shared_ptr at all. Making it syntactically consistent will just mislead more people. One could even argue that it needs to be made even less syntactically consistent with a smart pointer than it is now, because it's not like other smart pointers at all. Depending on how one looks at it, it represents either a TSD key or an auto_ptr with a thread-local storage class.
Besides, overall interface consistency is a sign of a good library design.
Good use of consistency is a sign of good design. Consistency alone is not.