Date: Sat, 18 Apr 2026 15:59:10 +0200
Hello,
On 18/04/2026 12:48, Muneem via Std-Proposals wrote:
> The point is that I tried to maintain as much detail as the standard
> allows me because again, this is a standard proposal and being abstract
> is important
It's actually the exact opposite: being detailed and specific is more
than important, it's essential.
You need to show the cost of runtime indexing a std::tuple on today's
implementations.
You also need to show your re-engineered tuple, for which runtime
indexing is faster/cheaper/better.
This is the entirety of the argument, isn't it? That is: that you need a
novel implementation in order to optimize the runtime indexing, and that
the same performances can't be achieved in existing libraries, not
without breaking ABI.
Only once this argument is proven we can move discussing whether this is
actually worth the addition to the standard library.
The point is that without this _hard data_ the proposal is entirely
vacuous. It's a wish for a magical thing, that no one even knows if it
actually exists.
> Implementation details and assumptions always lead to some incorrectness on all sides.
It's the opposite. The argument "this is better" needs to be grounded in
data, which requires showing the implementation details.
My 2 c,
--
Giuseppe D'Angelo
On 18/04/2026 12:48, Muneem via Std-Proposals wrote:
> The point is that I tried to maintain as much detail as the standard
> allows me because again, this is a standard proposal and being abstract
> is important
It's actually the exact opposite: being detailed and specific is more
than important, it's essential.
You need to show the cost of runtime indexing a std::tuple on today's
implementations.
You also need to show your re-engineered tuple, for which runtime
indexing is faster/cheaper/better.
This is the entirety of the argument, isn't it? That is: that you need a
novel implementation in order to optimize the runtime indexing, and that
the same performances can't be achieved in existing libraries, not
without breaking ABI.
Only once this argument is proven we can move discussing whether this is
actually worth the addition to the standard library.
The point is that without this _hard data_ the proposal is entirely
vacuous. It's a wish for a magical thing, that no one even knows if it
actually exists.
> Implementation details and assumptions always lead to some incorrectness on all sides.
It's the opposite. The argument "this is better" needs to be grounded in
data, which requires showing the implementation details.
My 2 c,
--
Giuseppe D'Angelo
Received on 2026-04-18 13:59:12
