Date: Sat, 18 Apr 2026 23:32:58 -0400
On Sat, Apr 18, 2026 at 11:14 PM Muneem via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 1. Even if optional was proposed, I am just backing it up even more, like I hope there is no copyright on proposals now.
> 2. My gurrenties are meant to be backed by mathematical points based of the behvaiour of all rather than my own, which is why I was reluctant to add benchmarking code. (but I will now)
> 3. Actually making [] fast for large tuples would require some optimization techniques. returning std::variant<T...>& has an issue because it would mean that some std::variant<T...> must exist, such that a vector of it, which you explained, The issue with that comes for large objects like std::variant<std::ofstream, int>.
> 4. The idea of storing a std::variant<T&...> in an array for every object is the tuple and then simply indexing it, sounds better because it dosent have the high memory overhead while having high performance gains (indexing an array is O(1) ).
A lot of things might "sound better" than others. Copy-on-write
strings "sound better" than other kinds of strings. But in practice,
they are not. Decisions shouldn't be made on things that "sound
better"; it takes a *lot* of specialized knowledge of low-level
programing and modern system design to be able to know a priori when
these kinds of optimizations might be necessary.
Note that if you're actually going to do benchmarking, your tests need
to consider the entire package. That is, you cannot *just* test
runtime indexing performance. You do more with tuples than just
indexing them. They're value types; they get copied a lot. A fair
benchmark must look into the slowdown caused by having to copy the
larger, book-keeping object compared to a proper `std:tuple`. That is,
you need to answer the question of how much runtime indexing relative
to copying must you do before the savings (if any) from book-keeping
exceeds the cost due to copying.
"Large tuples" are not exactly common, so profiling needs to show at
what size scale having bookkeeping information becomes overall better
than not doing bookkeeping.
<std-proposals_at_[hidden]> wrote:
>
> 1. Even if optional was proposed, I am just backing it up even more, like I hope there is no copyright on proposals now.
> 2. My gurrenties are meant to be backed by mathematical points based of the behvaiour of all rather than my own, which is why I was reluctant to add benchmarking code. (but I will now)
> 3. Actually making [] fast for large tuples would require some optimization techniques. returning std::variant<T...>& has an issue because it would mean that some std::variant<T...> must exist, such that a vector of it, which you explained, The issue with that comes for large objects like std::variant<std::ofstream, int>.
> 4. The idea of storing a std::variant<T&...> in an array for every object is the tuple and then simply indexing it, sounds better because it dosent have the high memory overhead while having high performance gains (indexing an array is O(1) ).
A lot of things might "sound better" than others. Copy-on-write
strings "sound better" than other kinds of strings. But in practice,
they are not. Decisions shouldn't be made on things that "sound
better"; it takes a *lot* of specialized knowledge of low-level
programing and modern system design to be able to know a priori when
these kinds of optimizations might be necessary.
Note that if you're actually going to do benchmarking, your tests need
to consider the entire package. That is, you cannot *just* test
runtime indexing performance. You do more with tuples than just
indexing them. They're value types; they get copied a lot. A fair
benchmark must look into the slowdown caused by having to copy the
larger, book-keeping object compared to a proper `std:tuple`. That is,
you need to answer the question of how much runtime indexing relative
to copying must you do before the savings (if any) from book-keeping
exceeds the cost due to copying.
"Large tuples" are not exactly common, so profiling needs to show at
what size scale having bookkeeping information becomes overall better
than not doing bookkeeping.
Received on 2026-04-19 03:33:11