For the record, I'm in favor of standardizing anonymous structs with the
same semantics as anonymous unions - simply insert the names of its
elements in the enclosing scope. I can't think of any drawbacks. Also, a
more extreme approach - allow constexpr overloads of `operator.`. The two
are not mutually exclusive :)

On Fri, Mar 8, 2024 at 4:56 PM Mihail Mihaylov <mihail.mihailov_at_[hidden]>
wrote:

> I came up with this (quite ugly) implementation:
>
> struct Vec3 {
> union {
> float my_vec[1];
> float x;
> };
>
> float y;
> float z;
> };
> This will probably be flagged by sanitizers and some compilers as unsafe,
> but I believe it's standard-compliant and does what's asked for.
>
>
>
>
>
> On Fri, Mar 8, 2024 at 2:53 PM Jens Maurer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On 08/03/2024 00.23, veronica alphonso via Std-Proposals wrote:
>> > The issue i see about making anonymous structs/classes standard, is
>> that now something as confusing as this could be allowed:
>> >
>> > // on the global namespace...
>> > struct
>> > {
>> > int x;
>> > };
>> >
>> > void foo()
>> > {
>> > .x = 42;
>> > // what? so x is some kind of weird SDM/global now?
>>
>> What is "SDM"?
>>
>> > // what is its lifetime?
>> > }
>>
>> We already have anonymous unions, suitably restricted to being
>> members of classes only.
>>
>> Given those restrictions, how much of the problem space would
>> anonymous structs address?
>>
>> Jens
>>
>>
>> > El jue, 7 mar 2024 a las 23:17, Sebastian Wittmeier via Std-Proposals (<
>> std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>)
>> escribió:
>> >
>> > __
>> >
>> > Dear Veronica,
>> >
>> > what about your mentioned alternative of anonymous unions and
>> structs?
>> >
>> > They could be made standard-compliant.
>> >
>> > And would need less language changes.
>> >
>> >
>> >
>> > Would they have problems with UB due to which element is the active
>> one? When used in your use case?
>> >
>> >
>> >
>> > Best regards,
>> >
>> > Sebastian
>> >
>> >
>> > -----Ursprüngliche Nachricht-----
>> > *Von:* veronica alphonso via Std-Proposals <
>> std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>> > *Gesendet:* Do 07.03.2024 23:55
>> > *Betreff:* [std-proposals] Subscript aliasing
>> > *An:* std-proposals_at_[hidden] <mailto:
>> std-proposals_at_[hidden]>;
>> > *CC:* veronica alphonso <verodeving_at_[hidden] <mailto:
>> verodeving_at_[hidden]>>;
>> > In C++ there isn't a standard-compliant way of creating named
>> aliases of c-like array elements. In certain contexts, it is preferred to
>> access these these array elements with a named identifier that is bounded
>> to that particular array entry, e.g:
>> >
>> > union
>> > {
>> > float my_vec[3];
>> > struct
>> > {
>> > float x, y, z;
>> > };
>> > };
>> >
>> > However, anonymous structs/classes are only
>> >
>> > --
>> > Std-Proposals mailing list
>> > Std-Proposals_at_[hidden] <mailto:
>> Std-Proposals_at_[hidden]>
>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>> >
>> >
>> > --
>> > Std-Proposals mailing list
>> > Std-Proposals_at_[hidden] <mailto:
>> Std-Proposals_at_[hidden]>
>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>> >
>> >
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.