Date: Sat, 18 Apr 2026 09:57:12 -0400
On Sat, Apr 18, 2026 at 9:21 AM Muneem via Std-Proposals
<std-proposals_at_[hidden]> 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).
> 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.
This may sound insulting, but do you know what it means to provide
evidence for something?
If you own a car, and you're driving it, then you're pulled over and
asked to provide evidence that your vehicle is registered to you, you
could say that registration is a legal framework that exists and that
it's a real thing. You could explain that we as a society have all
agreed that registration is good, and that societies that don't have
that aren't as good as ours. You could even cite laws and the specific
debates on the subject.
But none of that is evidence that *your* vehicle is registered *to you*.
That's the kind of thing we're asking for.
A philosophical diatribe on the importance of optimization and example
cases where improved performance required a new type is *not*
answering the question being asked. Citing philosophers on the nature
of programming is not answering the question being asked.
You are being asked why *your* specific proposed type needs to be a
new type instead of a `std::tuple`. An answer to that question needs
to look at the performance of your theorized code using `std::tuple`,
and then look at the performance of your theorized code using your
`runtime_tuple`. The answer must be a practical statement based on
observable, independently verifiable evidence about this specific
type.
And if you're not going to provide that because you don't think you
should have to, then you need to at least explain why it is that you
don't think you should have to.
<std-proposals_at_[hidden]> 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).
> 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.
This may sound insulting, but do you know what it means to provide
evidence for something?
If you own a car, and you're driving it, then you're pulled over and
asked to provide evidence that your vehicle is registered to you, you
could say that registration is a legal framework that exists and that
it's a real thing. You could explain that we as a society have all
agreed that registration is good, and that societies that don't have
that aren't as good as ours. You could even cite laws and the specific
debates on the subject.
But none of that is evidence that *your* vehicle is registered *to you*.
That's the kind of thing we're asking for.
A philosophical diatribe on the importance of optimization and example
cases where improved performance required a new type is *not*
answering the question being asked. Citing philosophers on the nature
of programming is not answering the question being asked.
You are being asked why *your* specific proposed type needs to be a
new type instead of a `std::tuple`. An answer to that question needs
to look at the performance of your theorized code using `std::tuple`,
and then look at the performance of your theorized code using your
`runtime_tuple`. The answer must be a practical statement based on
observable, independently verifiable evidence about this specific
type.
And if you're not going to provide that because you don't think you
should have to, then you need to at least explain why it is that you
don't think you should have to.
Received on 2026-04-18 13:57:27