1.I dont want that optimization but if the implementation sees it as fit
then it would.
2. The reason for the std::variant<T&...> to be proposed is to avoid the
exact space overhead that you are talking about.
3.std::array<std::variant<double, int, float>, 3> isn't guaranteed to be
fast, similarly it might encourage people to make many variants of this
implementation, which again is ad hoc and messy. What needs to exist is a
standard interface that the implementation can implement in whatever way it
sees fit, so that the runtime tuple is fast and people dont reinvent the
wheel. In fact, in your case, you also had a temptation to reconsider:
std::fixed_variant_array<double, int, float>, which again means that on
large scale, many people will implement many of these, leading to a mess
like openssl's C api implementation where everything openssl made and
little to nothing is borrowed from the C standard library, which in my
case, made me be scared of cryptography and networking libraries for a
whole year.