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

2521. [fund.ts.v2] weak_ptr's converting move constructor should be modified as well for array support

Section: [fund.ts.v2::memory.smartptr.weak.const] Status: TS Submitter: Tim Song Opened: 2015-07-25 Last modified: 2017-07-30

Priority: 2

View all issues with TS status.


Addresses: fund.ts.v2

[memory.smartptr.weak.const] altered the constraints on weak_ptr's constructor from const weak_ptr<Y>& and const shared_ptr<Y>&. The constraints on the converting move constructor from weak_ptr<Y>&& was not, but should be, similarly modified.


Daniel adjusts wording to lib. fund. v2. As link to the originating proposal: The discussion in this issue refers to wording changes that were requested by N3920.

[2016-11-08, Issaquah]

Adopted during NB comment resolution

Proposed resolution:

This wording is relative to N4529.

  1. At the end of [memory.smartptr.weak.const], add:
    [Drafting note: The current paragraph [memory.smartptr.weak.const] p2 is incorrectly declared as Requires element, but it does not describe a requirement, instead it describes a "template constraint" which are elsewhere always specified within a Remarks element because it describes constraints that an implementation (and not the user) has to meet. See LWG 2292 for a suggestion to introduce a separate new specification element for this situation. This has also been fixed in the current working draft. — end drafting note]

    weak_ptr(weak_ptr&& r) noexcept;
    template<class Y> weak_ptr(weak_ptr<Y>&& r) noexcept;

    -?- Remark: The second constructor shall not participate in overload resolution unless Y* is compatible with T*.

    -?- Effects: Move-constructs a weak_ptr instance from r.

    -?- Postconditions: *this shall contain the old value of r. r shall be empty. r.use_count() == 0.