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

Non grammatical term initializer is used like a language construct but not defined #3197

Open
sdkrystian opened this issue Aug 24, 2019 · 4 comments

Comments

@sdkrystian
Copy link
Contributor

sdkrystian commented Aug 24, 2019

While the grammatical term initializer has a definition, initializer as used throughout the standard is not defined anywhere, and since it is used as if it is a langauge construct, a definition should be specified, just like it is in the C11 standard. Such a definition should include grammatical initializers, as well as initializer-clauses (for function calls as the arguments are initializers, but not initializers)

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

See also #2847.

@jensmaurer
Copy link
Member

jensmaurer commented Sep 30, 2019

Editorial teleconference: Defining a term "initializer" is problematic, because the very definition could be confused with the grammarterm. But we do something similar for "expression". This would be helped if grammar would use a different font; see #323. Maybe turn uses of grammarterms into links to their definition (will make them blue).
In any case, defer until we have distinct presentation for grammarterms vs. defined terms.

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Sep 30, 2019
@jensmaurer
Copy link
Member

We now have a distinct presentation for grammarterms vs. defined terms.

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

Editorial meeting: We want /initializer/ plus function arguments plus return/throw operands and other operands (e.g. co_await) and to overloaded operators. -> function arguments after rewriting. Sometime determine the kind of initialization from /initializer/, except that you don't in the other cases. Maybe embody that in the transition from /initializer/ to initializer.

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Feb 10, 2020
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

2 participants