@jwakely in my proposed change, there's no change to the applicability of "well-formed". The change is to the applicability of "well-defined behavior" in the case where the unique_ptr contains a nullptr. If I understand the standardese correctly, "well-defined behavior" can be dependent on runtime values.

Doh, you're quite right, I misread the diff, sorry.

Now that I've remembered how to read, I think the "shall not throw exceptions" requirement should only apply to the get() != nullptr case. The deleter is allowed to throw exceptions in the general case, just not when invoked by unique_ptr.

Thanks for the update.

It might be easier to use the new specification structure that the standard library clauses are migrating to:

Mandates: The expression get_deleter()(get()) is well-formed.

Expects: If get() != nullptr, the expression get_deleter()(get()) has well-defined behavior and does not throw exceptions.

But somebody else is already working on doing that.

Whichever structure we use, this is a requirement that says "if this expression isn't well-defined, then it's undefined", which is a tautology. The "shall not throw" part is still useful though.

I stumbled across this because I was curious as to whether the standard required a null check on the part of the deleter. I think it's still helpful to say that there is no requirement for get_deleter()(nullptr) to have well-defined behaviour. Is there maybe a better way of expressing that?

Well, you could add a note (as in "[Note: blah -- end note]") to say that the result of get_deleter() is never invoked with a null pointer value, and thus no requirements are imposed on the deleter for that argument value.

Were I to specify these destructors in a green field, I'd write simply:

Effects: Equivalent to: if (get()) get_deleter()(get());

and not bother with explicit requirements.

(Note that "no effects" is just as wrong here as virtually every place we use it in the Library: pointer can be a user-defined type, so the null test is a user-observable effect.)

@CaseyCarter, I fully agree. However, introducing "Equivalent to" in an editorial issue is usually ... not what we do. @zygoloid?

Please rebase and fix the conflicts, then force-push.

Superseded by #4736