Created on 2013-07-24.00:00:00 last changed 40 months ago
[Moved to DR at the November, 2014 meeting.]
Proposed resolution (June, 2014):
Change 6 [basic] paragraph 3 as follows:
An entity is a value, object, reference, function, enumerator, type, class member, template, template specialization, namespace, parameter pack, or this.
Change 6.9 [basic.types] paragraph 11 as follows:
If two types T1 and T2 are the same type, then T1 and T2are layout-compatible types . [Note: Layout-compatible enumerations are described in 10.2 [dcl.enum]. Layout-compatible standard-layout structs and standard-layout unions are described in 12.2 [class.mem]. —end note]
Change 6.9.2 [basic.compound] paragraph 3 as follows:
...The value representation of pointer types is implementation-defined. Pointers to
cv-qualified and cv-unqualified versions (6.9.3 [basic.type.qualifier]) oflayout-compatible types shall have the same value representation and alignment requirements (6.11 [basic.align]). [Note:...
Insert the following as a new paragraph before 12.2 [class.mem] paragraph 16 and change paragraphs 16 through 18 as follows:
Two standard-layout struct (Clause 12 [class]) types are layout-compatible if
they have the same number of non-static data members and corresponding non-static data members (in declaration order) have layout-compatible types(6.9 [basic.types]).
union (Clause 12 [class]) typesare layout-compatible if they have the same number of non-static data members and corresponding non-static data members (in any order) have layout-compatible types (6.9 [basic.types]).
If a standard-layout union contains two or more standard-layout structs that share a common initial sequence, and if the standard-layout union object currently contains one of these standard-layout structs, it is permitted to inspect the common initial part of any of them. Two standard-layout structs share a common initial sequence if corresponding members have layout-compatible types and either neither member is a bit-field or both are bit-fields with the same width for a sequence of one or more initial members.
When the effect of cv-qualification on layout compatibility was previously discussed (see issue 1334), the question was resolved by reference to the historical origin of layout compatibility: it was a weakening of type correctness that was added for C compatibility, mimicking exactly the corresponding C specification of compatible types in this context and going no further. Because cv-qualified and cv-unqualified types are not compatible in C, they were not made layout-compatible in C++.
Because of specific use-cases involving std::pair and the like, however, and in consideration of the fact that cv-qualified and cv-unqualified versions of types are aliasable by the rules of 6.10 [basic.lval], the outcome of that question is worthy of reconsideration.
|2017-02-06 00:00:00||admin||set||status: drwp -> cd4|
|2015-05-25 00:00:00||admin||set||status: dr -> drwp|
|2015-04-13 00:00:00||admin||set||messages: + msg5392|
|2014-11-24 00:00:00||admin||set||status: tentatively ready -> dr|
|2014-07-07 00:00:00||admin||set||messages: + msg5080|
|2014-07-07 00:00:00||admin||set||status: drafting -> tentatively ready|
|2014-03-03 00:00:00||admin||set||status: open -> drafting|