On Thu, May 4, 2023 at 10:40 AM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Thursday, 4 May 2023 05:27:30 PDT Lauri Vasama via Std-Proposals wrote:
> > That's right. My intention is not at all to try to force Microsoft's hand.
> > Their hesitation to implement [[no_unique_address]] serves to demonstrate
> > the problem with the ignorability of attributes, though of course there is
> > no problem if attributes never affect program behaviour, but that
> > particular cat is now out of the bag. I can't speak for Microsoft of
> > course, but i believe they would not have the same objection to
> > implementing no_unique_address if its use was ill formed in compiler
> > versions or language modes where it is not supported.
>
> Do you have any other example besides NUA?
>
> Because if the problem is only NUA, then let's *fix* it and make it a real
> keyword that cannot be ignored.

The current NUA is built on a very small amount of *very* weasley
language. This is deliberate; the only effects it has are on things
that the standard already defined as unspecified or
implementation-defined. To make it into something that cannot be
ignored means making it a concrete feature with effects that are not
just unspecified or implementation-defined. They have to be things
that are detectable and guaranteeable by the standard. The standard
has to effectively say that the layout of a type containing zero-sized
subobjects shall match the layout of the same type without those
zero-sized subobjects.

So... how do you do that?

A few years ago, I went through the process of trying to work through
how empty types and zero-sized subobjects might work. I went through a
few revisions of the idea. And ultimately, the biggest problem was
satisfying what I've come to call the "Unique identity rule":
[intro.object]/9 in C++20:

> Two objects with overlapping lifetimes that are not bit-fields may have the same address if
one is nested within the other, or if at least one is a subobject of
zero size and they are of different types;
otherwise, they have distinct addresses and occupy disjoint bytes of storage.

This rule creates chaos when it comes to defining when a subobject can
be zero-sized, as I outline here:
https://github.com/NicolBolas/Proposal-Ideas/blob/main/Stateless%20Subobjects.md#unique-identity-problem-identity
About a third of the text in that proposal is dedicated to analzying
the problem and detailing possible solutions, all of which are some
form of awful.

If you want to take a crack at that, be my guest, but it's not nearly
as trivial as you might think. Unless you're going to have the
standard explicitly spell out layout rules byte-for-byte, unless
you're just going to standardize the Itanium ABI or something, this is
going to be incredibly difficult.