3548. shared_ptr construction from unique_ptr should move (not copy) the deleter

Section: [util.smartptr.shared.const] Status: C++23 Submitter: Thomas Köppe Opened: 2021-05-04 Last modified: 2023-11-22 15:47:43 UTC

Priority: Not Prioritized

View other active issues in [util.smartptr.shared.const].

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

View all issues with C++23 status.


The construction of a shared_ptr from a suitable unique_ptr rvalue r (which was last modified by LWG 2415, but not in ways relevant to this issue) calls for shared_ptr(r.release(), r.get_deleter()) in the case where the deleter is not a reference.

This specification requires the deleter to be copyable, which seems like an unnecessary restriction. Note that the constructor unique_ptr(unique_ptr&& u) only requires u's deleter to be Cpp17MoveConstructible. By analogy, the constructor shared_ptr(unique_ptr<Y, D>&&) should also require D to be only move-, not copy-constructible.

[2021-05-17; Reflector poll]

Set status to Tentatively Ready after eight votes in favour during reflector poll.

[2021-06-07 Approved at June 2021 virtual plenary. Status changed: Voting → WP.]

Proposed resolution:

This wording is relative to N4885.

  1. Modify [util.smartptr.shared.const] as indicated:

    template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);

    -28- Constraints: Y* is compatible with T* and unique_ptr<Y, D>::pointer is convertible to element_type*.

    -29- Effects: If r.get() == nullptr, equivalent to shared_ptr(). Otherwise, if D is not a reference type, equivalent to shared_ptr(r.release(), std::move(r.get_deleter())). Otherwise, equivalent to shared_ptr(r.release(), ref(r.get_deleter())). If an exception is thrown, the constructor has no effect.