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

[expr.prim.lambda.closure] Ambiguous parsing of implementation freedom #7570

Open
brevzin opened this issue Jan 17, 2025 · 0 comments
Open

Comments

@brevzin
Copy link
Contributor

brevzin commented Jan 17, 2025

The second sentence in paragraph 3 reads:

An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program other than by changing:

  • the size and/or alignment of the closure type,
  • whether the closure type is trivially copyable ([class.prop]), or
  • whether the closure type is a standard-layout class ([class.prop]).

I think the intent of this sentence is: "the implementation isn't allowed to alter any observable behavior other than by changing these things" (i.e. the implementation can't change anything other than the size, alignment, etc.) But it really strongly reads to me that "the implementation may define the closer type differently [...] other than by changing" (i.e. the implementation can change anything except for the size, alignment, etc.) Which is the exact opposite of what I think the intended meaning is.

If we worded it this way instead, I think it would be impossible to misread:

An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program, except that an implementation may alter:

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

No branches or pull requests

1 participant