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

[meta.rel] is_­nothrow_­convertible does not clearly require nothrow destruction LWG 3400, LWG 2116 #3576

Open
frederick-vs-ja opened this issue Dec 22, 2019 · 5 comments
Labels
lwg Issue must be reviewed by LWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.

Comments

@frederick-vs-ja
Copy link
Contributor

By @Dani-Hub , is_nothrow_convertible considers destruction of the converted object (if To is an object type) or the temporary (if To is a reference type and the temporary to bind would be created) by design. And known implementations (msvc, libc++, libstdc++) behave correctly.

For example, given a type Weird defined as

struct Weird {
  Weird(int) noexcept {}
  ~Weird() noexcept(false) {}
};

Then std::is_nothrow_convertible_v<int, Weird> is false.

However, I suspect that wording in [meta.rel]/5 only requires the well-formedness, and whether the destruction after the initialization of To is considered as part of the conversion is not mentioned.
So "the conversion, as defined by is_­convertible" in the specification of is_nothrow_convertible might not be precisely defined, and may lead to unintended comprehension, e.g. std::is_nothrow_convertible_v<int, Weird> can be true since the converting constructor itself is noexcept, although destruction of Weird is not.

@jensmaurer
Copy link
Member

Could you please be a bit more explicit why you believe a change in this area would be editorial, i.e. the desired effects are already implied by other normative wording?

@frederick-vs-ja
Copy link
Contributor Author

It looks like an LWG issue and is related to LWG 2116 IMO, so I mailed to LWG at first.
But Daniel Krügler replied me with

Since existing compilers do not violate that expectation there is IMO
currently no reason to open an issue for this.

It seems that the issue can be treated as editorial.

@jensmaurer
Copy link
Member

Just because no implementation disagrees doesn't mean an issue is editorial. The question is what the normative words of the standard say (and what they possibly neglect to say).

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Dec 26, 2019
@jensmaurer
Copy link
Member

Editorial meeting: Should become an LWG issue.

@jensmaurer jensmaurer added lwg Issue must be reviewed by LWG. and removed decision-required A decision of the editorial group (or the Project Editor) is required. labels Feb 10, 2020
@Dani-Hub
Copy link
Member

A corresponding library issues exists now: LWG 3400

@jensmaurer jensmaurer changed the title [meta.rel] Wording for is_­nothrow_­convertible might not cleary enough to indicate the destruction [meta.rel] Wording for is_­nothrow_­convertible might not cleary enough to indicate the destruction LWG 3400, LWG 2116 Feb 5, 2021
@jensmaurer jensmaurer added the not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking. label Feb 5, 2021
@jensmaurer jensmaurer changed the title [meta.rel] Wording for is_­nothrow_­convertible might not cleary enough to indicate the destruction LWG 3400, LWG 2116 [meta.rel] is_­nothrow_­convertible does not clearly require nothrow destruction LWG 3400, LWG 2116 Feb 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lwg Issue must be reviewed by LWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.
Projects
None yet
Development

No branches or pull requests

3 participants