@CaseyCarter , @jwakely, what do you think?

@jwakely , ping.

We already got one: https://cplusplus.github.io/LWG/issue3588 It was promptly closed as NAD. My preference was to just rely on the noexcept but the consensus was strongly NAD.

@tkoeppe , looks like this is ready.

Because it's undefined with the current spec, it's theoretically possible for the implementation to omit the EH code to call terminate() in case the deleter throws, although neither GCC nor Clang provides any way to do that today (I don't know about MSVC). I've mused in GCC's bugzilla about a new attribute that would be something like [[gnu::nothrow]] but would imply a stronger form of noexcept(true) saying no exceptions are possible and terminate won't be called either. We could use that here. It would be UB if something with that attribute throws, which matches the contract here.

(Sorry, off-topic.)

Because it's undefined with the current spec, it's theoretically possible for the implementation to omit the EH code to call terminate() in case the deleter throws, although neither GCC nor Clang provides any way to do that today (I don't know about MSVC). I've mused in GCC's bugzilla about a new attribute that would be something like [[gnu::nothrow]] but would imply a stronger form of noexcept(true) saying no exceptions are possible and terminate won't be called either. We could use that here. It would be UB if something with that attribute throws, which matches the contract here.

Ironically enough, we have __declspec(nothrow) with this exact meaning which is notably not used in our implementation of unique_ptr. If someone were to ask us to use it in unique_ptr, we'd almost certainly tell them to make their deleter noexcept/__declspec(nothrow) instead.