Skip to content

[basic.def.odr] Fix grammatical error in p17 #6441

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions source/basic.tex
Original file line number Diff line number Diff line change
Expand Up @@ -804,8 +804,8 @@

\pnum
If, at any point in the program,
there is more than one
reachable unnamed enumeration definition in the same scope
there are multiple
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
there are multiple
there are two or more

Copy link
Member Author

@Eisenwave Eisenwave Mar 28, 2025

Choose a reason for hiding this comment

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

Both your suggestion and my suggestion are grammatically correct. I'm not attached to my wording.

What about the bigger picture though? There are over 120 uses of "multiple" in N5008, and many of them are used in a "two or more" way. For example, [dcl.init.general] p21 says:

The same identifier shall not appear in multiple designators of a designated-initializer-list.

  • If "multiple" means "zero or more", then {} is ill-formed.
  • If "multiple" means "one or more", then { .x = 0 } is ill-formed.
  • If "multiple" means "two or more", that seems to be the desired behavior.
  • If it means "numerous, as in, a lot", then { .x = 0, .x = 0 } is well-formed because two is not that many.

I agree that it's not a good term because it has so many possible interpretations (even though as in the example above, only one of these makes sense); I'd just like to address the bigger picture while we're at it.

I feel like we should make a decision in the specification guidelines regarding this. If we decide that "multiple" is bad (which I support), then I'm happy to change this wording. Otherwise, I'm just reusing an existing wording idiom, and the change would be somewhat arbitrary. This may be a language barrier, but I don't see how the use of "multiple" here is any different from the countless other uses of "multiple" as in "two or more" throughout the standard. To me it seems like it's either bad nowhere, or bad everywhere. This case doesn't look special to me, if that's what you're pointing out.

reachable unnamed enumeration definitions in the same scope
that have the same first enumerator name and
do not have typedef names for linkage purposes\iref{dcl.enum},
those unnamed enumeration types shall be the same; no diagnostic required.
Expand Down