On Fri, Apr 17, 2026 at 9:19 AM Muneem via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 1. What I meant by the freedom to optimize was the freedom to have whatever mechanics that suits runtime indexing to be used to implement that particular specialization of the tuple, I used the term optimization losely for which I am really sorry, but the point is very similar to how vectors can optimize traditional arrays by providing move semantics.
> 2. The issue with a union of pointers is the possibility of null pointers, which means that you will have to do at least one check during conversation or many checks on every access, both of which are highly undesirable and the latter will mutate the meaning of pointers by not allowing it to be null. This is why it is better to have newer mechanisms that are to be implemented by every implementation. In the case of reference wrappers, they are just wrappers around references, that's all they really are.

That's not true at all. A `variant<Ts&...>` cannot be given a null
pointer because it is given *references* to objects. You can't get a
null reference (or if you do, something's already broken), so it does
not need to check to see if the internal pointer is not null.

Note that because of this, `optional<T&>` can be implemented as just a
pointer, with a null pointer internally being used to represent an
unengaged `optional`. Obviously a `variant<Ts&...>` can't do that, but
my point is that it's already OK for interfaces that take references
to assume that they aren't null references.

> 3. It is inappropriate because references are really just references to objects, and in this way they differ from pointers because they are an alias rather than a flexible arrow that you can point around like in the case of pointers.

And yet, you can do this to `optional<T&>`. You can make it
"valueless," change which `T` it references, etc. The core mechanics
of how `optional` works did not change between having a `T` and a
`T&`. Nor should they for `variant<Ts&...>`.