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

[dcl.enum] This is not where layout-compatible is defined #700

Merged
merged 1 commit into from Jun 16, 2016

Conversation

AaronBallman
Copy link
Contributor

There's a spurious definition of layout-compatible hiding in dcl.enum when it really lives in basic.types.

@zygoloid
Copy link
Member

This is the definition of layout-compatible for enumerations, and is referenced by the definition of layout-compatible in general in [basic.types]/11:

"Two types cv1 T1 and cv2 T2 are layout-compatible types if T1 and T2 are the same type, layout-compatible enumerations (7.2), or layout-compatible standard-layout class types (9.2)."

How about this instead:

Two enumeration types are \defn{layout-compatible enumerations} if they have the same

@zygoloid
Copy link
Member

It looks like a similar change is warranted in [class.mem]. We probably also want the index entry to be "layout-compatible!enumerations" rather than "layout-compatible enumerations".

@AaronBallman
Copy link
Contributor Author

I thought about that approach, but since we don't appear to use "layout-compatible enumeration" (or "layout-compatible class") anywhere else in the standard aside from this instance, it seemed more sensible to remove the definition from dcl.enum instead of adding one-time use definitions.

@zygoloid
Copy link
Member

Well, [dcl.enum] is where we define what "layout-compatible" means for enumeration types. The wording in [basic.types] is really just saying that the definition is split across two other clauses. It makes much more sense for the index entries to point to the useful definition, in my opinion.

@AaronBallman AaronBallman force-pushed the layout-compat branch 2 times, most recently from a58901e to d2d8a33 Compare April 15, 2016 13:24
@AaronBallman
Copy link
Contributor Author

I've come around to your logic, and I think I've implemented what you were suggesting (though I freely admit that index entries are new to me, so I may not have done the entries properly).

Two standard-layout struct (Clause~\ref{class}) types are layout-compatible if
their common initial sequence comprises all members and bit-fields of
\indextext{layout-compatible!classes}%
Two standard-layout struct (Clause~\ref{class}) types are \defn{layout-compatible classes}
Copy link
Member

Choose a reason for hiding this comment

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

I think the term we put in the index here should be "layout-compatible class" (or maybe "layout-compatible!class") "layout-compatible classes". Use \defnx to specify different index text from the body text.

@AaronBallman AaronBallman force-pushed the layout-compat branch 3 times, most recently from f7a3ccc to 4b5b218 Compare June 13, 2016 13:03
@tkoeppe
Copy link
Contributor

tkoeppe commented Jun 13, 2016

Looks good! @zygoloid: PTAL.

@zygoloid zygoloid merged commit d335c89 into cplusplus:master Jun 16, 2016
FrankHB pushed a commit to FrankHB/draft that referenced this pull request Jul 9, 2016
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

Successfully merging this pull request may close these issues.

None yet

3 participants