-
Notifications
You must be signed in to change notification settings - Fork 774
Bring pointer terminology up to date #6174
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
Conversation
Why is this edtiorial? Unless it is obvious that a change is non-normative (e.g. because it changes a note or example, or fixes a typo), there should be some rationale explaining the intended meaning and why that's unambiguous, and why the change retains that meaning. Otherwise such change requests should probably be CWG issues. |
Updated with an explanation (and some extra changes). |
Specifically, in: * [expr.prim.lambda.closure]/8, /11 * [expr.const]/13.3 * [temp.arg.nontype]/3
@jensmaurer I think some CWG input here would be good, but it seems like a nice improvement. |
The first part (about lambdas) feels editorial, the other parts fix normative defects and thus should be addressed by a CWG issue. |
CWG meeting consensus Nov 11: good |
@jensmaurer Could you check again that the entire PR as it is now is editorial? |
@jensmaurer Ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please.
Pointer values are not addresses ([basic.compound]/3), this updates some of the old text to use proper terminology. The intent of the wording is clear, and this PR does not change its normative meaning.
I'm not sure if changing 'address of' to 'pointer representing the address of' is an improvement, so the following are left untouched:
Also, in [temp.arg.nontype]/3, the text should probably also include past-the-end pointers, but that's not editorial.