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

[C++17 DIS comment 002] update [intro.defs] to use text that can be substituted for the use of the term #1714

Closed
zygoloid opened this issue Sep 6, 2017 · 8 comments
Assignees
Labels
ballot-comment Response to an NB or ISO comment on a ballot
Milestone

Comments

@zygoloid
Copy link
Member

zygoloid commented Sep 6, 2017

Per ISO directives, definitions should be drafted to replace the term in context. We need to survey the existing definitions and rephrase to suit this requirement.

@zygoloid zygoloid changed the title [C++17 DIS comment 001] update [intro.defs] to use text that can be substituted for the use of the term [C++17 DIS comment 002] update [intro.defs] to use text that can be substituted for the use of the term Sep 6, 2017
@zygoloid zygoloid added the ballot-comment Response to an NB or ISO comment on a ballot label Sep 6, 2017
@zygoloid zygoloid modified the milestone: C++17 IS Sep 6, 2017
@zygoloid zygoloid self-assigned this Sep 7, 2017
@zygoloid
Copy link
Member Author

First pass at tackling this is here:

https://github.com/cplusplus/draft/compare/master...zygoloid:iso-2?expand=1

I've split this into a multiple changes for easier review, and because I think we may want to adopt only some of them. Specifically, I would propose taking 886b293 and d9b5f40 for C++17, but not a38a131.

Thoughts?

@jwakely
Copy link
Member

jwakely commented Sep 12, 2017

886b293 addresses the comment nicely.

d9b5f40 is great. (On the same subject, are we even allowed to have a second set of defns in lib-intro.tex? Those should also be in Clause 3, or not use the Terms and definitions format, no? Not something to fix for C++17 though).

@tkoeppe
Copy link
Contributor

tkoeppe commented Sep 12, 2017

Both changes look very nice!

@jensmaurer
Copy link
Member

886b293 just highlights some of our more dodgy definitions, e.g. "argument of throw expression" (it's probably an operand these days that throw-expression is a first-class expression in clause 8 [expr]).

@jensmaurer
Copy link
Member

jensmaurer commented Sep 12, 2017

@jwakely regarding the "on the same subject note": I agree. Further, maybe we should review clause 3 afresh: It's not clear to me which definitions should go there as opposed to being inline. Something like "access", which is essentially only used in the memory model subsection, is in Clause 3, but other more global definitions aren't, it seems.

@zygoloid
Copy link
Member Author

I've been contemplating whether to suggest we start to issue the standard in two parts (language and library). If we do that, each part gets to have its own "Terms and Definitions". Seems like something to talk over with at least Herb before making changes to the Terms and Definitions in Clause 20.

@jensmaurer
Copy link
Member

@zygoloid: We do have interdependencies between language and library; in particular the language refers to the library for some of its semantics (cf. operator new or Gor's coroutines) and (of course) the library fully depends on the language. That essentially requires synchronized releases of library and language, without a clear hierarchy between the two, unlike some other multipart standards where part -1 is "common terms and defintions", part -2 specifies the geometry of a screw, and part -3 specifies measuring apparatus / approaches to determine whether a given screw satisfies part -2.

@zygoloid
Copy link
Member Author

First two commits pushed to c++17, all three pushed to master.

Resolution: ACCEPTED

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ballot-comment Response to an NB or ISO comment on a ballot
Projects
None yet
Development

No branches or pull requests

4 participants