Date: Mon, 19 Jun 2023 17:18:43 -0400
On Mon, Jun 19, 2023 at 4:29 PM M.P. via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> > How so? c1 is a punned reference to u, and c2 is a punned reference to
> > u.i, so [basic.lval]/11 applies, does it not? Meanwhile, reading u.c
> > for c3 would access an inactive variant.
>
> 'u.c' is pointer-interconvertible with 'u' (and 'u.i'), so '(char&)u'
> refers to 'u.c'.
Pointer-interconvertibility is always a relationship between two
objects ([basic.compound]/4). If u.c exists, then the object u.c is
pointer-interconvertible with the object u. But in this case, the only
existing objects are u and u.i; the data member u.c does not refer to
an object. So based on a literal reading, I'd say that
pointer-interconvertibility doesn't apply, and the resulting
references refer to the same objects ([expr.static.cast]/14).
More generally, if such a conversion could ever result in a pointer or
reference to (the storage corresponding to) an inactive data member,
then there could be ambiguity regarding *which* data member the
pointer or reference actually refers to, in cases where multiple data
members have the same type. Such a reading sounds pretty unworkable,
without additional wording along the lines of "the selected data
member is whichever one does not result in UB, if such a member
exists".
<std-discussion_at_[hidden]> wrote:
>
> > How so? c1 is a punned reference to u, and c2 is a punned reference to
> > u.i, so [basic.lval]/11 applies, does it not? Meanwhile, reading u.c
> > for c3 would access an inactive variant.
>
> 'u.c' is pointer-interconvertible with 'u' (and 'u.i'), so '(char&)u'
> refers to 'u.c'.
Pointer-interconvertibility is always a relationship between two
objects ([basic.compound]/4). If u.c exists, then the object u.c is
pointer-interconvertible with the object u. But in this case, the only
existing objects are u and u.i; the data member u.c does not refer to
an object. So based on a literal reading, I'd say that
pointer-interconvertibility doesn't apply, and the resulting
references refer to the same objects ([expr.static.cast]/14).
More generally, if such a conversion could ever result in a pointer or
reference to (the storage corresponding to) an inactive data member,
then there could be ambiguity regarding *which* data member the
pointer or reference actually refers to, in cases where multiple data
members have the same type. Such a reading sounds pretty unworkable,
without additional wording along the lines of "the selected data
member is whichever one does not result in UB, if such a member
exists".
Received on 2023-06-19 21:18:56