Forgot to post my previous response to mr.marcin on the list itself:
>No, this is not type safety. Please do not change the meaning of
words. Beside assigning float to int is a well defined operation.
***ANSWER***
1. It was just an example to help simplify things, since it applies to any
example.
2. It's called narrowing, assigning float to int is narrowing and potential
loss of precision as a consequence of narrowing.
>Funny that you mention ABI as is in many cases outside of compiler
control and once set can't be never changed.
And how tuple break the zero abstraction principle? If you make such
outlandish claims you need to prove it, and you did not do it
anywhere.
***ANSWER***
Tuples don't have the book keeping information required for a programmer
runtime index heterogeneous list. Mr.Simom proposed that we can expand
tuples, but that would break zero abstraction principle.

On Wed, 8 Apr 2026, 6:33 am Marcin Jaczewski, <marcinjaczewski86_at_[hidden]>
wrote:

> śr., 8 kwi 2026 o 02:54 Muneem <itfllow123_at_[hidden]> napisał(a):
> >
> > >No, this is not type safety. Please do not change the meaning of
> > words. Beside assigning float to int is a well defined operation.
> > ***ANSWER***
> > 1. It was just an example to help simplify things, since it applies to
> any example.
> > 2. It's called narrowing, assigning float to int is narrowing and
> potential loss of precision as a consequence of narrowing.
>
> And this has nothing in common with type safety. In some use cases it
> is even pefiecaly fine to have loss of precision there.
> If loss of precision is not wanted you can always use `SafeInt` or
> something like this to prevent some miss use of `int`.
> And this means it is irrelevant to "runtime polymorphism" discussion.
>
> > >Funny that you mention ABI as is in many cases outside of compiler
> > control and once set can't be never changed.
> > And how tuple break the zero abstraction principle? If you make such
> > outlandish claims you need to prove it, and you did not do it
> > anywhere.
> > ***ANSWER***
> > Tuples don't have the book keeping information required for a programmer
> runtime index heterogeneous list. Mr.Simom proposed that we can expand
> tuples, but that would break zero abstraction principle.
> >
>
> No it does not, tuples do not need anything like this. And Sebastian
> (not Simon) example did show that.
> `Disapch` type is built on top of tupe and thus does not affect
> performance of tuple itself.
> This type has required bookkeeping but it is fully aligned with zero
> cost abstraction.
> Why? because your code has the same bookkeeping and thus you can't avoid
> it.
>
>
> >
> > On Wed, 8 Apr 2026, 5:38 am Marcin Jaczewski, <
> marcinjaczewski86_at_[hidden]> wrote:
> >>
> >> śr., 8 kwi 2026 o 02:06 Muneem via Std-Proposals
> >> <std-proposals_at_[hidden]> napisał(a):
> >> >
> >> > Summary of my points (to keep it simple for those who didn't
> understand):
> >> >
> >> > ***Type Safety is the priority***:
> >> > With std::variant, you can assign a float to an object that should
> only be an int. That’s not type-safe. My type_set(selector) fixes this—once
> the runtime index picks the type, it’s fixed. You can't just swap it later.
> >> >
> >>
> >> No, this is not type safety. Please do not change the meaning of
> >> words. Beside assigning float to int is a well defined operation.
> >>
> >> >
> >> > ****Compiler Freedom = Speed***:
> >> > I’m calling for an implementation-defined container. This lets the
> compiler decide the best way to move or copy data (registers, stack, etc.)
> based on the ABI. It’s faster because the compiler isn’t fighting a rigid
> library structure. The compiler has the same freedom on when it
> instantiates type_set(selector) into T^. Tuples aren't implementation
> defined, since they have to provide some gurrenties and modifying tuples to
> fix this breaks the zero cost abstraction principle.
> >> >
> >>
> >> Funny that you mention ABI as is in many cases outside of compiler
> >> control and once set can't be never changed.
> >> And how tuple break the zero abstraction principle? If you make such
> >> outlandish claims you need to prove it, and you did not do it
> >> anywhere.
> >>
> >> >
> >> > --
> >> > Std-Proposals mailing list
> >> > Std-Proposals_at_[hidden]
> >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>