My response to Mr.Marcin latest response:
>previous conversation:
>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***(my previous answer that he responded to)
> 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.
>Mr.marcin's current response:

>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.
***ANSWER***
1. The int example was just an example of how you can assign anything to a
variant. Like a float to an int, but this applies to assigning an
std::ofstream to a int also.
2. It has to do with runtime polymorphism be Use you sometimes want a
specific memory location to have a fixed type that's set at runtime. So the
type itself while may be "polymorphic" in the sense that it's decided at
runtime, but you still want strict type checking, do that if you assign a
std::ofstream to an int, you get a exception thrown at you.


> Previous conversation:
> >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***(my previous answer that he responded to)
> 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.
>Mr.marcin current response:
>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.

***ANSWER***
1. In the case of the example that Mr.Sebastian showed, the tuple couldn't
allow for changes *inside* it's layout. In my case, the compiler can use an
array of pointers to different types or use any other layout of the tuple
itself so that it fits the branching code that the compiler generated. You
can't do that with tuples, it's one of the reasons some of us use flat maps
instead of maps because while no one is forcing you to use std::map, you
still have to use it if you want an associative container implemented as a
balanced binary tree, but with flat maps, you have the choice to have that
while also having a say in the representation of how it is stored under the
hood.


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
>