[unique.ptr.single] Throwing after 079f7d3b02d can be well-defined

[JohelEGP]

079f7d3 added noexcept to certain constructors that had the precondition that some initialization didn't throw. Before, the effects was that throwing results in undefined behavior according to [structure.specifications]. 079f7d3 didn't remove the preconditions, but an exception throw within a noexcept function is well-defined. Could this have been an oversight?

[jensmaurer]

No, throwing an exception in these situation is still a precondition violation -> undefined behavior. The unconditional "noexcept" just means no exception will escape, but regardless you still need to play by the rules (i.e. satisfy the preconditions).

[JohelEGP]

https://timsong-cpp.github.io/cppwp/n3337/unique.ptr.single.ctor
Looks like std::unique_ptr<T, D>{} has had UB since C++11 for the right D. Even though it could just have been a call to std::terminate.

[jwakely]

079f7d3 added noexcept to certain constructors that had the precondition that some initialization didn't throw.

Is that the right commit ID? It didn't add any noexcept.

I agree that making it UB is bad. We should just rely on the compiler to terminate. We should try to reduce the places where programs have unnecessary undefined behaviour.

But I think this needs an lwg issue.

[JohelEGP]

079f7d3 added noexcept to certain constructors that had the precondition that some initialization didn't throw.

Is that the right commit ID? It didn't add any noexcept.

No.

I agree that making it UB is bad. We should just rely on the compiler to terminate. We should try to reduce the places where programs have unnecessary undefined behaviour.

But I think this needs an lwg issue.

Yes. This seems like a low-hanging fruit compared to other sources of library UB. I'll take a look again and submit a LWG issue.