On Mon, Dec 4, 2023 at 5:02 PM Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Wouldn't it be good to have at least a manual way to specify, and a standard way to test, whether a type supports overlapping? E.g. a trait or concept?

The problem is this: what does "supports overlapping" even mean? Is
there a list of things that makes a type not "support overlapping"?

Most programmers don't do things that would break that to begin with,
and quite a few of them don't even know what that means. So it would
be reasonable to presume that the default is true. But are the writers
of types that don't "support overlapping" going to activate the flag
or whatever correctly? And since it's not clear what things switch off
"support" for overlapping, most programmers wouldn't necessarily think
to turn it on when they cross this boundary.

If we're going to make changes of this magnitude, it'd be better to
just have a standard feature for empty objects, a version of
"no_unique_address" that

1. Has explicit, required layout support, and
2. Only applies to empty types. Like, the compiler will error out if
you use them on non-empty types.

That way, "no_unique_address" can just be a thing people do for
padding nonsense.