ś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