Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[unique.ptr.single] Remove redundant preconditions after 079f7d3b02d #4871

Closed
wants to merge 1 commit into from

Conversation

JohelEGP
Copy link
Contributor

@JohelEGP JohelEGP commented Sep 6, 2021

Resolves #4872.

@jensmaurer
Copy link
Member

jensmaurer commented Sep 6, 2021

This doesn't look right.

"noexcept" means no exception escapes, but violating a precondition (e.g. when moving a deleter throws) is still undefined behavior.

Can you show which normative statement implies the struck text?

@JohelEGP
Copy link
Contributor Author

JohelEGP commented Sep 6, 2021

There's none. My assumption was that the precondition existed to prevent users from examining the unique_ptr object after such a throw, or alternatively, to not have to define the state in such a case. That shouldn't be possible after it was marked noexcept, though. I can't think of any other reason why to declare UB, so it doesn't make sense to me that it's still a precondition.

This is definitely not editorial, though. If you agree, I'll close this PR and its issue, and consider submitting an LWG issue.

@jensmaurer
Copy link
Member

Well, for once, having to catch all exceptions to call terminate for a noexcept violation is overhead you might want to avoid. (We don't require the deleter's move operation to be declared noexcept, we just require that it does not throw an exception for this particular move invocation.)

Anyway, this is not editorial, so I'd appreciate if you closed this issue and submitted an LWG issue if you believe there is a defect in the specification (I don't believe so).

@JohelEGP JohelEGP closed this Sep 6, 2021
@JohelEGP JohelEGP deleted the unique.ptr.single branch September 6, 2021 20:41
@jwakely
Copy link
Member

jwakely commented Sep 7, 2021

Well, for once, having to catch all exceptions to call terminate for a noexcept violation is overhead you might want to avoid. (We don't require the deleter's move operation to be declared noexcept, we just require that it does not throw an exception for this particular move invocation.)

The compiler is going to provide thenoexcept guarantee anyway, unless unique_ptr is decorated with some non-standard extension to tell the compiler that an exception cannot happen. In practice, nobody does that, so the terminating branch is still emitted by the compiler (although a good implementation can arrange for the terminate with no overhead anyway).

Anyway, this is not editorial, so I'd appreciate if you closed this issue and submitted an LWG issue if you believe there is a defect in the specification (I don't believe so).

Yes, this should be an LWG issue.

@Dani-Hub
Copy link
Member

Dani-Hub commented Sep 7, 2021

It would be nice to have the link to this draft PULL request as part of the corresponding LWG issue submission text.

@JohelEGP
Copy link
Contributor Author

JohelEGP commented Sep 7, 2021

It would be nice to have the link to this draft PULL request as part of the corresponding LWG issue submission text.

Would that be the case even though there are more signatures that are noexcept yet have the precondition that an operation doesn't exit with an exception? This PR wouldn't suficce as a Proposed Resolution.

@Dani-Hub
Copy link
Member

Dani-Hub commented Sep 7, 2021

I only recommend that when an LWG issue is submitted as a consequence and strong relation to an issue/pull request from this project, it would be nice to refer to that issue/pull request in the text of the LWG issue submission.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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