Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [intro.object]
Link to reflector thread (if any):
Issue description:
It's currently specified in [intro.object] p7.2 that the no_unique_address attribute unconditionally makes a subobject potentially-overlapping, even if __has_cpp_attribute(no_unique_address) is 0.
There're already some open CWG issues with [[no_unique_address]] (CWG2545 and CWG2866). If some implementation decides to ignore [[no_unique_address]], it seems better to make such an implementation (e.g. MSVC) free from these issues. For such an implementation, it's perhaps better to make [[no_unique_address]] not to bring the potential-overlapping property in. See also CWG2759.
By the way, I guess that [intro.object] p7.2 should say "a member subobject corresponding to a non-static data member" instead. But perhaps this should belong to another issue.
Suggested resolution:
Modify [intro.object] p7.2 as indicated.
- (7.2) if the value of
__has_cpp_attribute(no_unique_address) ([cpp.cond]) is nonzero, a non-static data member declared with the no_unique_address attribute.
Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [intro.object]
Link to reflector thread (if any):
Issue description:
It's currently specified in [intro.object] p7.2 that the
no_unique_addressattribute unconditionally makes a subobject potentially-overlapping, even if__has_cpp_attribute(no_unique_address)is0.There're already some open CWG issues with
[[no_unique_address]](CWG2545 and CWG2866). If some implementation decides to ignore[[no_unique_address]], it seems better to make such an implementation (e.g. MSVC) free from these issues. For such an implementation, it's perhaps better to make[[no_unique_address]]not to bring the potential-overlapping property in. See also CWG2759.By the way, I guess that [intro.object] p7.2 should say "a member subobject corresponding to a non-static data member" instead. But perhaps this should belong to another issue.
Suggested resolution:
Modify [intro.object] p7.2 as indicated.