Revised 2017-10-16 at 05:08:47 UTC

Tentative Issues


3001(i). weak_ptr::element_type needs remove_extent_t

Section: 23.11.2.3 [util.smartptr.weak] Status: Tentatively Ready Submitter: Stephan T. Lavavej Opened: 2017-07-14 Last modified: 2017-08-01

Priority: 0

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

View all issues with Tentatively Ready status.

Discussion:

C++17's shared_ptr<T>::element_type is remove_extent_t<T>, but weak_ptr<T>::element_type is T. They should be the same, but this was lost over time.

First, N4562 "Working Draft, C++ Extensions for Library Fundamentals, Version 2" 8.2.2 [memory.smartptr.weak] specified:

namespace std {
namespace experimental {
inline namespace fundamentals_v2 {

  template<class T> class weak_ptr {
  public:
    typedef typename remove_extent_t<T> element_type;

(The typename here was spurious.)

Then, P0220R1 "Adopt Library Fundamentals V1 TS Components for C++17 (R1)" listed:

This obscured the fact that the Library Fundamentals TS had altered weak_ptr::element_type.

Finally, P0414R2 "Merging shared_ptr changes from Library Fundamentals to C++17" missed the change to weak_ptr::element_type, so it wasn't applied to C++17.

Peter Dimov has confirmed that this was unintentionally lost, and that "boost::weak_ptr defines element_type in the same way as shared_ptr".

[ 2017-07-17 Moved to Tentatively Ready after 6 positive votes on c++std-lib. ]

Proposed resolution:

This resolution is relative to N4659.

  1. Edit 23.11.2.3 [util.smartptr.weak], class template weak_ptr synopsis, as indicated:

    template<class T> class weak_ptr {
    public:
      using element_type = remove_extent_t<T>;
      […]
    };
    

3024(i). variant's copies must be deleted instead of disabled via SFINAE

Section: 23.7.3.1 [variant.ctor] Status: Tentatively Ready Submitter: Casey Carter Opened: 2017-10-10 Last modified: 2017-10-15

Priority: Not Prioritized

View other active issues in [variant.ctor].

View all other issues in [variant.ctor].

View all issues with Tentatively Ready status.

Discussion:

The specification of variant's copy constructor and copy assignment operator require that those functions do not participate in overload resolution unless certain conditions are satisfied. There is no mechanism in C++ that makes it possible to prevent a copy constructor or copy assignment operator from participating in overload resolution. These functions should instead be specified to be defined as deleted unless the requisite conditions hold, as we did for the copy constructor and copy assignment operator of optional in LWG 2756.

[ 2017-10-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

Proposed resolution:

This wording is relative to N4687.

  1. Change 23.7.3.1 [variant.ctor] as indicated:

    variant(const variant& w);
    

    -6- Effects: If w holds a value, initializes the variant to hold the same alternative as w and direct-initializes the contained value with get<j>(w), where j is w.index(). Otherwise, initializes the variant to not hold a value.

    -7- Throws: Any exception thrown by direct-initializing any Ti for all i.

    -8- Remarks: This function shall not participate in overload resolutionconstructor shall be defined as deleted unless is_copy_constructible_v<Ti> is true for all i.

  2. Change 23.7.3.3 [variant.assign] as indicated:

    variant& operator=(const variant& rhs);
    

    […]

    -4- Postconditions: index() == rhs.index().

    -5- Remarks: This function shall not participate in overload resolutionoperator shall be defined as deleted unless is_copy_constructible_v<Ti> && is_copy_assignable_v<Ti> is true for all i.