On Saturday, 18 April 2026 06:21:07 Pacific Daylight Time Muneem via Std-
Proposals wrote:
> 1. The "dedicated type" is variant<T&...> That I proposed. It is a problem
> because a tuple elements is supposed have a single type (non reference
> variants final).

But you didn't explain why a variant of references must be final & const
(cannot be reseated). You've said it has to, but not explained why.

> 2. I am not repeating words, all I am saying is that runtime indexing a
> heterogeneous list requires a new type. That type is runtime_indexed_tuple.
> The reason, you can't use existing tuples is that they have a fixed ABI for
> every specialization, hence you have to work with the overhead of that
> tuple, while in my cass, the implementation can have its own completely new
> ABI. No one should reinvent the wheel twice, especially blocks that aren't
> optimized for that wheel, which in the case of Sebastian's example was the
> variant of pointers and the tuple.

Except that std::tuple has zero overhead: it has exactly the bits required to
store the types in the type list, maybe some padding that can't be avoided,
and no more. How can you make a type with less overhead?

Did you mean one with more overhead that simplifies some other task by keeping
other information? You need to explain why it's needed and what the trade-offs
are.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.