Proposed resolution:

This wording is relative to N4594.

1. Change [util.smartptr.shared] p1 as indicated:

   -1- The shared_ptr class template stores a pointer, usually obtained via new. shared_ptr implements semantics of shared ownership; the last remaining owner of the pointer is responsible for destroying the object, or otherwise releasing the resources associated with the stored pointer. A shared_ptr object is empty if it does not own an objecta pointer.

Latest draft (N4567) [util.smartptr.shared] p1 says:

A shared_ptr object is empty if it does not own a pointer.

Please note that it says "own a pointer". This definition was added as the resolution for LWG defect 813.

[util.smartptr.shared.const] p8 says about the effect of shared_ptr(nullptr_t p, D d):

Effects: Constructs a shared_ptr object that owns the object p and the deleter d.

Please note that it says "owns the object". This was intentionally changed from "the pointer" as a part of resolution for LWG defect 758, to cover nullptr_t case.

Since shared_ptr(nullptr, d) owns an object of type nullptr_t, but does not own a pointer, it is said as "empty" by a strict reading of the above mentioned definition in [util.smartptr.shared] p1.

These cause a contradiction:

[util.smartptr.shared.const] p9 sets a postcondition use_count() == 1 on shared_ptr(nullptr, d). But [util.smartptr.shared.obs] p7 says that the return value of use_count() is "0 when *this is empty".

Proposed wording changes:

Replace the last 2 words in [util.smartptr.shared] p1 from

[…] empty if it does not own a pointer.

to

[…] empty if it does not own an object.

Note that shared_ptr(nullptr_t) is defined to be empty in synopsis in [util.smartptr.shared].

constexpr shared_ptr(nullptr_t) noexcept : shared_ptr() { }

It could be less confusing if shared_ptr(nullptr, d) could be defined to be empty. But it seems too late to change that (which means changing whether the deleter is called or not, see this Stackoverflow article). Then I'm proposing just fix the contradiction.