[ 2017-06-02 Issues Telecon ]

Resolve as NAD

[ 2017-02 in Kona, LEWG recommends NAD ]

We just removed std::shared_ptr<>::unique() because it's misleading at best (especially in the face of weak_ptr). Resolving this is far larger than issues-processing — it would require significant design discussion and potentially an ABI break (stashing a mutex in the shared_ptr control block).

[ 2009 Santa Cruz: ]

Moved to NAD Future.

[ 2009-07-26 Howard sets to Tentatively NAD Future. ]

I took an online poll and got 3 votes for NAD and 3 for NAD Future. Personally I prefer NAD Future as this does refer to an extension that could conceivably be considered beyond C++0X.

However such an extension would need to solve a couple of problems:

1. What is the interface for such a conversion when the shared_ptr does not have unique ownership? Throw an exception? Create a null unique_ptr? Undefined behavior?

2. How does one handle custom deleters given to the shared_ptr constructor?

   I do not believe it is possible to implement a general answer to this question. The shared_ptr deleter is a run time (or construction time) characteristic. The unique_ptr deleter is a compile time characteristic. In general one can not know to what type of unqiue_ptr you are converting to.

   One answer is for the user of the conversion to specify the deleter type and perhaps throw an exception if the specification turns out to be incorrect.

   Another answer is for the conversion to only be valid when the underlying deleter is default_delete. We would probalby need to specify that this is indeed the underlying deleter of a shared_ptr when a custom deleter is not given in the constructor.

At any rate, there are non-trivial design issues which would need to be implemented and tested in the field for usability prior to standardization.

[ 2009-07 post-Frankfurt: ]

The rationale for the omission of a release() member function from shared_ptr is given in: http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm

The implementation of such a member is non-trivial (and maybe impossible), because it would need to account for the deleter.

[ Peter Dimov adds: ]

This is basically a request for shared_ptr<>::release in disguise, with all the associated problems. Not a good idea.

[ Summit: ]

We look forward to a paper on this topic. We recommend no action until a paper is available. We believe that the shared pointer must use the default deleter for the conversion to succeed.

Addresses US 78 [CD1]

There is presently no way to convert directly from a shared_ptr to a unique_ptr. Add an interface that performs the conversion.