On Thu, 5 May 2022, Jₑₙₛ Gustedt via Liaison wrote:

> This would have made that clearer, but I think that this already
> follows, anyhow. The type of `bar` is indeed `int const` and not
> `int`. The `const` of the surrounding structure comes from the part in
> 6.3.2.1p1 that you cited
>
> ... and if it is a structure or union, does not have any
> member (including, recursively, any member or element of all
> contained aggregates or unions) with a const-qualified type.
>
> This specification doesn't exclude unnamed members, and so
> `<anonymous>.bar` is not a modifiable lvalue.

I think what this wording about modifiable lvalues actually says is that
my_foo is not a modifiable lvalue (because it has a const-qualified
(anonymous) member) - not anything about whether my_foo.bar is a
modifiable lvalue. That is, it's about carrying the "not a modifiable
lvalue because const" property up from members to the containing structure
or union (even when that containing structure or union is not itself
const-qualified) - not down from that structure or union to members.

I agree that my_foo.bar *should* have type const int (and so not be a
modifiable lvalue), because anonymous structs and unions should simply
provide shorter syntax for corresponding code where names are added for
those members, without any semantic differences. If the contained struct
weren't anonymous, the const int type would be achieved by 6.5.2.3#3:
my_foo.<anonymous> has const-qualified type and so my_foo.<anonymous>.bar
does. The question is how to make that clear in the specification when
the only explicit '.' operator is applied to a non-const-qualified
structure or union but there is a const-qualified anonymous structure or
union in the middle.

-- 
Joseph S. Myers
joseph_at_[hidden]