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

[except.spec] Exception specifications are declarations #7308

Conversation

AlisdairM
Copy link
Contributor

No description provided.

@AlisdairM AlisdairM changed the title Exception specifications are declarations [except.spec] Exception specifications are declarations Oct 16, 2024
@@ -4422,6 +4422,272 @@
\indextext{declaration!default argument|)}%
\indextext{declarator!meaning of|)}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be after the added text.

@@ -4422,6 +4422,272 @@
\indextext{declaration!default argument|)}%
\indextext{declarator!meaning of|)}

\rSec3[except.spec]{Exception specifications}%
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit uneasy putting this under "meaning of declarators", which focuses on the recursive decomposition.

Right after "function definitions" (two levels up) feels better to me. We talk an awful lot about a "function declaration having a non-throwing exception declaration" in the text, and a declarator isn't a complete declaration, so this feels like the wrong spot.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about after [dcl.fct.spec] instead?

Copy link
Member

@jensmaurer jensmaurer Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the section about decl-specifier. A noexcept-specifier isn't a decl-specifier. It's more like an attribute, considering its trailing placement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After carefully hunting through [decl], I think the best place for this right now is immediately following [dcl.fct] that has the grammar for the optional noexcept-specifier on a function (type) declaration.

I will get this branch into a non-conflicting state, and suggest we discuss further in Wrocław.

@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Oct 17, 2024
@AlisdairM
Copy link
Contributor Author

Is this PR still viable for C++26, moving a subclause (verbatim) from clause 14, exceptions, to clause 9, delcarations?

If not, please give it the C++29 milestone.
I will continue to respond to Jens feedback so this PR can be ready to land whenever it is appropriate (hopefully still for C++26!)

@tkoeppe
Copy link
Contributor

tkoeppe commented Oct 17, 2024

I'm not sure why this change should be tied to any particular publication schedule? We should discuss it on the merits, and then either proceed or drop it.

I'm missing a bit of a motivation and justification here, beyond the Core feedback that Jens has already started giving. Could you update the opening post with some justification?

@AlisdairM AlisdairM force-pushed the exception_specifications_are_declarations branch from 886de55 to aeece2c Compare October 17, 2024 14:00
@AlisdairM AlisdairM force-pushed the exception_specifications_are_declarations branch from aeece2c to 3570220 Compare October 17, 2024 14:08
@jensmaurer jensmaurer added the cwg Issue must be reviewed by CWG. label Oct 17, 2024
@jensmaurer
Copy link
Member

Instead of piecewise moving meat from [except], I think the logical next step is to actually dissolve [except] and distribute its contents to where it belongs. Which is a clause re-org, for C++29.

@jensmaurer jensmaurer added this to the C++29 milestone Oct 17, 2024
@tkoeppe
Copy link
Contributor

tkoeppe commented Oct 17, 2024

If you think that it's realistic to fully dissolve the clause, then do feel free to start a new issue with C++29 milestone!

@AlisdairM
Copy link
Contributor Author

Issue opened, tentatively aiming for C++29. See #7317.

@AlisdairM
Copy link
Contributor Author

Now that we have a new issue tracking the C++29 work, I have created a new branch with the full rework and dissolve: #7320. Further reviews and progress will happen on that PR.

@AlisdairM AlisdairM closed this Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG. needs rebase The pull request needs a git rebase to resolve merge conflicts.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants