Proposed resolution:

Add two new paragraphs directly to [unique.ptr.dltr] (before [unique.ptr.dltr.dflt]) with the following content:

The class template default_delete serves as the default deleter (destruction policy) for the class template unique_ptr.

The template parameter T of default_delete may be an incomplete type.

[ 2010-01-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[ 2009-11-17 Alisdair Opens: ]

LWG 1193 tries to support unique_ptr for incomplete types. I believe the proposed wording goes too far:

The template parameter T of default_delete may be an incomplete type.

Do we really want to support cv-void? Suggested ammendment:

The template parameter T of default_delete may be an incomplete type other than cv-void.

We might also consider saying something about arrays of incomplete types.

Did we lose support for unique_ptr<function-type> when the concept-enabled work was shelved? If so, we might want a default_delete partial specialization for function types that does nothing. Alternatively, function types should not be supported by default, but there is no reason a user cannot support them via their own deletion policy.

Function-type support might also lead to conditionally supporting a function-call operator in the general case, and that seems way too inventive at this stage to me, even if we could largely steal wording directly from reference_wrapper. shared_ptr would have similar problems too.

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

According to the general rules of [res.on.functions] p 2 b 5 the effects are undefined, if an incomplete type is used to instantiate a library template. But neither in [unique.ptr.dltr] nor in any other place of the standard such explicit allowance is given. Since this template is intended to be instantiated with incomplete types, this must be fixed.