This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 1031. Need `shared_ptr` conversion to a `unique_ptr`

Section: 20.3.2.2 [util.smartptr.shared] Status: NAD Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2018-06-23

Priority: Not Prioritized

View all other issues in [util.smartptr.shared].

View all issues with NAD status.

Discussion:

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.

[ 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.

[ Peter Dimov adds: ]

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

[ 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.

[ 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 Santa Cruz: ]

> Moved to NAD Future.

[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).

[2017-06-02 Issues Telecon]

Resolve as NAD

Proposed resolution: