Peter Dimov wrote:
Andrey Semashev:
Peter Dimov wrote: ....
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.
Agreed. And I for one would personally prefer to see a thread_specific_value instead of thread_specific_ptr in this case. But since we have a pointer here, I would like it to behave as a pointer. And if it has a feature that is similar to other well known pointers, I would like the feature to have a similar way of use. But that's my HO, after all.