This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++23 status.
shared_ptr
construction from unique_ptr
should move (not copy) the deleterSection: 20.3.2.2.2 [util.smartptr.shared.const] Status: C++23 Submitter: Thomas Köppe Opened: 2021-05-04 Last modified: 2023-11-22
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.
Discussion:
The construction of a shared_ptr
from a suitable unique_ptr
rvalue r
(which was last modified by LWG 2415(i), 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.
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.
Modify 20.3.2.2.2 [util.smartptr.shared.const] as indicated:
template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);-28- Constraints:
-29- Effects: IfY*
is compatible withT*
andunique_ptr<Y, D>::pointer
is convertible toelement_type*
.r.get() == nullptr
, equivalent toshared_ptr()
. Otherwise, ifD
is not a reference type, equivalent toshared_ptr(r.release(), std::move(r.get_deleter()))
. Otherwise, equivalent toshared_ptr(r.release(), ref(r.get_deleter()))
. If an exception is thrown, the constructor has no effect.