2520. N4089 broke initializing unique_ptr<T[]> from a nullptr

Section: 20.3.1.4.2 [unique.ptr.runtime.ctor] Status: C++17 Submitter: Ville Voutilainen Opened: 2015-07-19 Last modified: 2017-07-30

Priority: 2

View all issues with C++17 status.

Discussion:

According to the wording in 20.3.1.4.2 [unique.ptr.runtime.ctor]/1, this won't work: 

unique_ptr<int[], DeleterType> x{nullptr, DeleterType{}};

U is not the same type as pointer, so the first bullet will not do.
U is not a pointer type, so the second bullet will not do.

An easy fix would be to add a new bullet after the first bullet, like so:

[2015-10, Kona Saturday afternoon]

MC: Is it the right fix?

GR: It'd be awefully surprising if we had an interface that accepts null pointer values but not std::nullptr_t. I think the PR is good.

STL: Are any of the assignments and reset affected? [No, they don't operate on explicit {pointer, deleter} pairs.]

VV: This is already shipping, has been implemented, has been tested and works fine.

Move to Tentatively ready.

Proposed resolution:

This wording is relative to N4527.

  1. Change 20.3.1.4.2 [unique.ptr.runtime.ctor] as indicated:

    template <class U> explicit unique_ptr(U p) noexcept;
template <class U> unique_ptr(U p, see below d) noexcept;
template <class U> unique_ptr(U p, see below d) noexcept;

    -1- These constructors behave the same as the constructors that take a pointer parameter in the primary template except that they shall not participate in overload resolution unless either

    • U is the same type as pointer, or

    • U is nullptr_t, or

    • pointer is the same type as element_type*, U is a pointer type V*, and V(*)[] is convertible to element_type(*)[].