Proposed resolution:

This wording is relative to N4527.

1. Change [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(*)[].

[ 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.

According to the wording in [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:

• U is the same type as pointer, or

• U is nullptr_t, or

• pointer is the same type as element_type*, […]