-
Notifications
You must be signed in to change notification settings - Fork 7
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
CWG2590 [dcl.enum] Underlying type of enum should determine its size and alignment requirement #39
Comments
I think we want the phrasing from [basic.fundamental] p6 here. |
The rule from [basic.fundamental]/6 about the range being the same doesn't apply, though; the range is more restricted in the case of enumerations with non-fixed underlying type: http://www.eel.is/c++draft/dcl.enum#8 |
It seems that an enumeration type is not layout-compatible with its underlying type. Is this intended? |
There's still the question of layout compatibility:
The suggested resolution guarantees same size, representation and alignment; should layout compatibility follow? |
"Furthermore, each value of an enumeration has the same representation as the same value of the underlying type." should suffice, I think. We need "layout-compatible" only for "common initial sequence", which seems a fairly narrow use-case. I do recognize that two enumerations are layout-compatible if they have the same underlying type, so it seems plausible to also declare layout-compatibility between an enumeration and its underlying type. |
Thanks Jens; more thoughts. The fact that C++20 introduced P0466 Layout-compatibility and Pointer-interconvertibility Traits argues that this use case was considered important enough to add traits to assert its applicability (only recently implemented in gcc and msvc). Common initial sequence is applicable to C structs, e.g. for OS 'protocol' headers. Here, a first element of enum type can be a 'strong type' tag value encoding the trailing message fields. The existing specification guarantees that this is with a distinct CIS enum type which weakens its usage as a 'strong type' (without reflection there's no way to further check and assert enumerated values or their ids). It seems strictly better to allow pointer-interconvertibility with the underlying type. |
Pointer-interconvertible is unrelated to layout-compatible. "Layout-compatible" is only used for "common initial sequence" for unions. |
Thanks for the correction. The main thought was that punning between distinct enum types compromises the type system more than does access to the underlying type. The rationale for allowing enum-enum conversions may have been because 'they are integer types' C++23's value-returning Overlaying the information of two more richly structured types is a cross-cast, or Conclusion: |
Full name of submitter: Brian Bi
Reference (section label): [dcl.enum]
Issue description: [dcl.enum] explains how the underlying type of an enumeration is determined, and for scoped enumerations, specifies that the enumeration has the same set of values as the underlying type. I'm quite sure that it was intended that the enumeration has the same size and alignment requirement as its underlying type, but the current wording does not explicitly state this. I'm less sure of whether (analogously to [basic.fundamental]/6) it was intended that enumerations always have the same value representation as their underlying type and that every valid value of the enumeration always has the same representation as it does in the underlying type. I think the answer to both is "yes" because otherwise it would be hard to satisfy [dcl.enum]/9 (according to which identity of underlying types is sufficient for layout-compatibility). If so, it should be made explicit. If not, perhaps it would be appropriate to add a note indicating what is not guaranteed.
Suggested resolution: Insert the following paragraph after [dcl.enum]/8:
The text was updated successfully, but these errors were encountered: