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

Several issues about section [except.spec] #4561

Closed
xmh0511 opened this issue Mar 27, 2021 · 2 comments · Fixed by #4563
Closed

Several issues about section [except.spec] #4561

xmh0511 opened this issue Mar 27, 2021 · 2 comments · Fixed by #4563
Assignees

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Mar 27, 2021

Misusing of the wording "potentially-throwing" in these cases

any of the following constructs is potentially-throwing

a constructor selected by overload resolution in the implicit definition of the constructor for class X to initialize a potentially constructed subobject

any of the destructors for any of its potentially constructed subobjects is potentially-throwing or the destructor is virtual and the destructor of any virtual base class is potentially-throwing.

E implicitly invokes a function (...) that is potentially-throwing

AFAIK, the property "potentially-throwing" ascribes to an expression. That is, we may say an expression is potentially-throwing or not. However, we cannot say a constructor, destructor, or function is potentially-throwing. Maybe, we should say such an entity has the potentially-throwing exception specification

The statement for implicitly-declared assignment operator indicates this point

if the invocation of any assignment operator in the implicit definition is potentially-throwing.

So, for the first three bullets. Should we say that the invocation of the destructor, constructor, or function is potentially-throwing? Or, another way, such a constructor, destructor, or function has the potentially-throwing exception specification? That may make sense.

The redundant bullet of defining "potentially-throwing"

An expression E is potentially-throwing if

  • E implicitly invokes a function(...) that is potentially-throwing
  • any of the immediate subexpressions of E is potentially-throwing

In this case, Isn't that the last bullet can cover the former, as per

The immediate subexpressions of an expression E are

  • any function call that E implicitly invokes

The exception of a declaration that does not have a noexcept-specifier

unless it is a destructor or a deallocation function or is defaulted on its first declaration, in which cases the exception specification is as specified below

As specified below, the relevant rules do not only cover the case for defaulted on its first declaration but also cover the case for implicitly-declared. So, in order to be consistent, I think the introduction in this sentence should add the case for implicitly-declared into its exception cases.

@jensmaurer jensmaurer changed the title Serveral issues about section [except.spec] Several issues about section [except.spec] Mar 27, 2021
@jensmaurer
Copy link
Member

redundant bullet of defining "potentially-throwing"

The problem is that p6.1 talks about the postfix-expression of a function call, but for an implicit invocation of a function, there is no corresponding explicit source code that would match the grammar for postfix-expression.

implicitly-declared functions

The sentence starts with

If a declaration of a function does not have a noexcept-specifier ...

An implicitly-declared function does not have a declaration, so this sentence does not apply at all.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Mar 27, 2021

redundant bullet of defining "potentially-throwing"

The problem is that p6.1 talks about the postfix-expression of a function call, but for an implicit invocation of a function, there is no corresponding explicit source code that would match the grammar for postfix-expression.

implicitly-declared functions

The sentence starts with

If a declaration of a function does not have a noexcept-specifier ...

An implicitly-declared function does not have a declaration, so this sentence does not apply at all.

Well. So, the remaining issue is the first issue. function, constructor, or destructor cannot be said that they are potentially-throwing since they're not expressions.

An implicitly-declared function does not have a declaration, so this sentence does not apply at all.

The arguable place is, there's a sentence in the standard that says

An implicitly-declared special member function is declared at the closing } of the class-specifier. Programs shall not define implicitly-declared special member functions.

However, we would argue here, there's no explicit grammar in the translation unit related to a declaration. Hence, it may not be considered a declaration.

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 a pull request may close this issue.

2 participants