sob., 18 kwi 2026 o 15:21 Muneem <itfllow123_at_[hidden]> napisał(a):
>
> 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.
>

Again buzzwords, you repeat the same text without addressing issues
people have and answering questions.
Prove that your approach is better than multiple counter examples
people here post before.
Show concrete examples that clearly show these benefits. And do not
dump there blocks of random code, you need
show "Tony tables", and show that the compiler can make better code
there, if you can't then it means your idea is wrong.

If you do not do this and again reply only using some empty words and
unrelated quotes from Bjarne Stroustrup that I do not
see point to continuing this discussion as it goes in circles without
addressing core questions.

> On Sat, 18 Apr 2026, 4:08 pm Marcin Jaczewski, <marcinjaczewski86_at_[hidden]> wrote:
>>
>> sob., 18 kwi 2026 o 12:57 Muneem via Std-Proposals
>> <std-proposals_at_[hidden]> napisał(a):
>> >
>> > While your solution was ingenious and pretty clever, there are a few issues that can't be addressed well without standard library support:
>> > 1. The issue with the get_index function is that it returns a variant of pointers, and you can change the type variant currently holds, which is something that you should not be able to do since, hence leading to my proposal of a variant<T&...> , which since no existing ABI's depend on it, can have its own thing(ABI) specifically tuned for this purpose.
>>
>> This is not a problem, you fixated on irrelevant parts. Besides nobody
>> forcing you to use `std::variant` there could be dedicated type that
>> have more finning behavior.
>>
>> > 2. Your proposal dosent allow implementations to store book keeping information in a tuple, which leads to less "mechanical optimization". The reason current tuples aren't runtime indexed is because they aren't built for that.
>> > All this is to say that even though your solutions are ingenious and innovative, they are trying to make as less additions as possible, which is a issue because standard library isn't meant to be minimalistic but rather a library of generic "vocabulary types".
>>
>> No, what you suggest (as other point out) make overall code worse, if
>> you think the opposite is true you need to PROVE it, repeating
>> buzzwords will not convince anyone here.
>>
>>
>> >
>> >
>> > On Sat, 18 Apr 2026, 3:23 pm Sebastian Wittmeier via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>> >>
>> >> You want a simple way:
>> >>
>> >>
>> >>
>> >> That is possible today.
>> >>
>> >>
>> >>
>> >> https://onlinegdb.com/Het7pmsSr
>> >>
>> >>
>> >>
>> >> -> a std::tuple
>> >>
>> >> -> retrieving a variant by a runtime index
>> >>
>> >> -> passing it to a function
>> >>
>> >>
>> >>
>> >> One could improve by standardizing get_index
>> >>
>> >>
>> >>
>> >>
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: Muneem via Std-Proposals <std-proposals_at_[hidden]>
>> >> Gesendet: Sa 18.04.2026 06:34
>> >> Betreff: Re: [std-proposals] Extension to std::tuples to allow runtime indexing.
>> >> An: std-proposals_at_[hidden];
>> >> CC: Muneem <itfllow123_at_[hidden]>;
>> >> 1. Sorry that my first two answers weren't clear enough: in the first answer, the tag was for partial specialization and the in the second what I meant by tag was book keeping information.
>> >> 2. I get that by allowing book keeping information, my type isn't trivially copyable anymore, I am sorry that I didn't think about it properly, it didn't seem significant at of me answering. I also want emphasize that normally users want a specific runtime tuples, they don't want to think about ways to implement it or weather's it's trivially copyable or not because they really just don't care. If this proposal gets passed then with variants of T&... ,You could implement other kinds of tuples but normally you would not want to do that, normally you would want a simple way to define and use runtime indexed tuples. My proposal provides a standard interface for that.
>> >>
>> >> On Sat, 18 Apr 2026, 8:42 am Jason McKesson via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>> >>
>> >> On Fri, Apr 17, 2026 at 10:27 PM Muneem via Std-Proposals
>> >> <std-proposals_at_[hidden]> wrote:
>> >> >
>> >> > 1. My proposal uses a tag in std namespace and since std namespace is reserved, no one would be using it anyway(by defining their own tags).
>> >>
>> >> That changes nothing about what I said. None of my examples use
>> >> specific typenames; they're all based on template deduction, which is
>> >> done now.
>> >>
>> >> Look at implementations of `std::apply` and explain how it would work
>> >> with a tagged tuple without changing its implementation.
>> >>
>> >> > 2.i didn't meant a tag for current tuples because that's really not useful, since current tuples get their element from recursion,which though inefficient is efficient since it's at compile time. You will however need tags or other book keeping information at some point if you were to avoid such potentially inefficient recursive/looping patterns.
>> >>
>> >> >From the first sentence of your proposal:
>> >>
>> >> > This proposal provides a specialization of std::tuple that can be indexed at runtime.
>> >>
>> >> You're asking to make a specialization of `std::tuple`, which is
>> >> triggered by the use of a tag type.
>> >>
>> >> > 3. Copying a my tuple would also be trivially copyable and explicit conversion to normal tuples.
>> >>
>> >> That's not possible.
>> >>
>> >> Remember how I brought up copy-on-write `std::string` implementations?
>> >> That kind of implementation was made possible in C++98 by very
>> >> particular wording around pointer/reference/iterator invalidation.
>> >> C++11 shut down CoW strings by taking that particular wording away.
>> >>
>> >> I bring this up because a trivially copyable type cannot have pointers
>> >> to itself. Well, they cannot *maintain* those pointers being pointers
>> >> to themselves across a copy.
>> >>
>> >> If you have a type like this:
>> >>
>> >> ```
>> >> struct foo
>> >> {
>> >> int i = 30;
>> >> int *pi = &i;
>> >> };
>> >> ```
>> >>
>> >> Value initialization for this object will leave it in a state where
>> >> `pi` points to the `i` member of the object. But if you copy this
>> >> object, the new copy's `pi` will not point to its own `i` member; it
>> >> will point to the copied-from object's `i` member. Same goes for
>> >> movement.
>> >>
>> >> In order to guarantee that the copied `pi` is a pointer to the
>> >> internal object's `i` member and not someone elses, you need a copy
>> >> constructor (and move constructor):
>> >>
>> >> ```
>> >> struct foo2
>> >> {
>> >> foo2(foo2 const& other) : i{other.i}, pi{&i} {}
>> >>
>> >> int i = 30;
>> >> int *pi = &i;
>> >> };
>> >> ```
>> >>
>> >> `foo2` is not trivially copyable.
>> >>
>> >> If `runtime_tuple` is trivially copyable, that will forbid the
>> >> implementation from being able to maintain pointers to its members
>> >> across copy/move operations. That is, if you want bookkeeping
>> >> information to point to its members, it *cannot* be trivially
>> >> copyable.
>> >>
>> >> It's one thing or the other. You cannot have both.
>> >> --
>> >> Std-Proposals mailing list
>> >> Std-Proposals_at_[hidden]
>> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> >>
>> >> --
>> >> Std-Proposals mailing list
>> >> Std-Proposals_at_[hidden]
>> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> >>
>> >>
>> >> --
>> >> Std-Proposals mailing list
>> >> Std-Proposals_at_[hidden]
>> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> >
>> > --
>> > Std-Proposals mailing list
>> > Std-Proposals_at_[hidden]
>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals