Hi,

On Wed, 14 Oct 2020 11:20:17 -0400
Jason McKesson via Std-Discussion <std-discussion_at_[hidden]>
wrote:

> The language makes sense. Changing it as you suggest would make it
> make less sense. This is a problem caused by the Itanium ABI; it
> should be solved *by* the Itanium ABI. Whether they do it by treating
> private members correctly in accord with the standard, or by doing
> what you suggest, it's on them to implement the standard as it
> currently is.

Yes the language makes sense, it's a simple rule for common initial
sequences.

The Itanium ABI also makes sense, it uses the same layout rules for
[[no_unque_address]] members as for base subobjects. It allows library
implementations to switch from EBO to [[no_unique_address]] without
changing layout.

Both of these were the intent of the [[no_unique_address]] proposal[1],
as described in its FAQ:

> Q: Can a standard library switch from EBO to this attribute without an
> ABI break?
> The intent is that an ABI can specify the same layout rule for a
> member with the attribute as it does for a base class. In an ABI that
> makes that choice, yes.
> Q: Does this allow reuse of tail padding? (Eg, three bytes at the end
> of struct A { int n; char c; };)
> The general rule is that the layout is just like for a base class.
> Tail padding reuse is permitted for base classes, so it's also
> permitted for members with the attribute.
> ...
> Q: Does the attribute affect whether a type is standard-layout?
> No.
> Q: Does the attribute affect the "common initial sequence" rule?
> Yes. For two structs to be considered to have a common initial
> sequence, their initial sequences of common members must make
> consistent use of the attribute.

In short we have two conflicting intents here:
1. Allowing ABIs to use the same layout rules for [[no_unique_address]]
members and base class subobjects.
2. Allowing [[no_unique_address]] members in common initial sequences
(at arbitrary position).

We can't have both. The current wording chooses the second option, but
it doesn't reflect all the intents of the proposal, as it can't.

I think it's also worth submitting this as a core language issue. I
never submitted one so I wanted to float the problem here first. I
would be glad if more people chimed in with their opinion.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0840r2.html