1.references are a reference to a single object and variants are sum types,
and sum types are meant to withhold the core behaviour of the types that it
stores, which for normal types is obeying the const/volatile
qualifications, and to make sure they have a identify and there invariant
isnt invalidate. For references, it is to point to a single object for it's
whole life time(that is if references do have a lifetime)

2.I think that the variant of references should be in the proposal, since
the idea of a heterogeneous list and a variant of references are very
similiar. Basically, getting an element from the list is going to get an
element of a type that is potentially any of the types in T... , which
means that to get it efficiently, I should get a variant of pointers to
that object, but pointers can be null, and tuple elements always exist, so
If I want a reference to an element, I want to make sure that they can't be
nulled or changed, hence a variant of references is important. Infact,
other than this, there are no better use cases that pointers can't solve,
where as for normal sum type data, you can just use a reference to a
variant to deal with a variant of T.


On Sat, 18 Apr 2026, 6:59 pm Bjorn Reese via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Regarding variant with reference types.
>
> This should be a separate proposal.
>
> Extending std::optional with reference types was simpler, but that
> proposal had much more detail than your extension. Have a look at P2988
> to get a feel for the scope of such proposals.
>
> The proposal adds reference types to std::variant to make it work as
> a return type. It does not discuss other use-cases, and there are
> many open questions. For instance, it does not discuss rvalue-
> references, the lifetime extension of const-ref, the mixture of
> reference and non-reference types.
>
> There is no rationale for why variant with reference types cannot be
> valueless by exception. Assumably the run-time indexing of tuples has a
> precondition that the index should be within bounds. In this case, a
> possibility is to return a nullable variant when the index is out of
> bounds, and valueless by exception is a built-in nullable state for
> errors.
>
> There is no rationale for immutable type selection. Furthermore,
> immutable type selection deviates from the std::variant design, so it
> should not be introduced as a specialization of std::variant.
>
> Assignment logic seems to be based on the immutable type selection, but
> ignores the guidelines set out in P1683.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>