śr., 8 kwi 2026 o 04:22 Muneem <itfllow123_at_[hidden]> napisał(a):
>
> >What on earth is arguing for "comfortable"?? I ask for technical
> reasons why you need things like this and this is not the answer.
> ***ANSWER***
> 1. The issue with heterogeneous lists is the fact that they can allow any type, so:
> Selector(runtime index).print()
> A user would not use heterogeneous lists in such cases if the list can include sensitive information. Basically adding flexibility leads to a whole class of issues, and the fix to all of them is a expression type T^ for every T, so that the user can provide overloads for that.
>

How does this have anything to do with this proposal? If a user would
not use this construct in the first place, why change anything in it?
And even more, how would this new overload even fix this problem?


> >> I SAID: 3. The new T^ is important because it is what type_set(selector) decays into, If I had said that type_set(selector) decays to a T lvalue or a T xvlaue then that would require some modifications to them which would break the zero overbead principle.
>
> >Mr.Marcin asked:What modifications?
> ***ANSWER*** ($$$$1.1$$$$)
> For type_set(selector) to decay into T^ for every T in selector, the compiler would have a specific implementation defined constant representation of T^ that is efficient for this one instantiaton goal. T^ is a glvalue so it stores the information, but the layout of that information can differ from typical glvalues(lvalues and xvalues) to allow for this instantiation to be smoother. For example, an implementation may decide to focus on optimizations for merging multiple branches into one, for which instead of branching the second type_set(selector) instantiates into T^, it copies all the necessary information of type_set(selector) into T^ at instantion and branches when ever it thinks T^ should branch. For example:


Then you again contradict yourself as it is not like `T&` on assembly
level as you answered previously.
And layout cannot change, need be set by ABI as you can esay declare
`void Foo(int^);` and implement it in another Translation Unit.
This means you create pointless things as in place where it could be
useful; it's not needed as the compiler already sees everything and
use As-If rule optimizes it. But when compiler can't do this then your
new type do not diffrent to `Dispatch` class proposed as alternative.


> {1, 2, 2.2} selector(int);
> Type_set(selector) X=Selector(1);
> Type_set(selector) Y=Selector(2);
> Int a= X+Y+X*Y;

btw where is your "type safety" when here your trim `double` value
into `int`? It looks like you used this term previously without
considering its consequences.

> During every addition or multiplication, a branch would happen, but if the compiler wants, it can delay branching that should have happened at the instantiation of type_set(selector) into T^, and instead copy type_set(selector) into every T^, and then branches based of that. This can of course be one of many techniques implementation can choose to focus on based on the computer architecture and the specializations of the hardware of that time(for example if the ram has high bandwidth and more space to spare or not to copy type_select(selector) into every T^).

I think you confuse the semantics of code with its optimization. If
any use of `X^` will need to instantiate a new code path that cannot
be merged in any other path. Consider:
```
template<typename T>
int foo(T^ a)
{
    static int bar = 0;
    ++bar;
    return bar;
}

int main(int arg)
{
    {1, 2, 2.2} selectorA(int);
    {'a', 2, 3} selectorB(int);
    return foo(selectorA(arg)) + foo(selectorB(arg));
}
```
How many unique `bar` objects will need to be created? and what values
can be returned?

And if we replace `^` with `&` then will the answer change or not? If
the answer changes this will not be an expected thing for
majority of programmers. And if answers do not change then what point
in `^` as it does not give us anything there?
You need to instantiate this template template anyway, why not use
direclty `T&`?

> In short, ***a summary is***:
> 1.Deferred Branching: Instead of branching at the declaration, the compiler can treat T^ as a "variant-like" container that holds the state of the selector.
> 2.Implementation-Defined Representation: As you noted in (1.1), T^ can have a layout optimized for the specific architecture (e.g., leveraging high RAM bandwidth to copy state rather than performing expensive CPU branching).
> 3.Preserving Zero Overhead: If you modify lvalues to support this behavior, every existing C++ function using lvalues by value or reference would potentially incur the cost of checking for "selector based" data. T^ keeps this overhead for those willing to use heterogeneous lists.This also proves my point that by inventing newer expression types, you are trying not to hurt the existing features. It's like expanding your house horizontally means you don't have to make the lower floors strong, but vertically does, so adding newerr features is horizontal expansion, while expanding older ones is vertical.
>
> >"easy to implement" no it isn't, adding new value category can be
> effective breaking change that will affect every code as for example:
>
> ```
> >struct Foo
> {
> void bar() &;
> void bar() &&;
> };
> ```
>
> >Now its need `void bar() ^;` too.
>
> ***ANSWER***
> No, I said it multiple times that T^ can decay into T& or T&& or even T if T^ overload doesn't exist. You don't need that. The decaying priority list is as follows:
> If const lvalue overload is there then const lvalue, if lvalue overload then lvalue, if const lvalue reference overload then const lvalue, and so on (for rvalues as well). This priority list makes overloading for T^ fit right into the existing overloading rules, without having to make additional complicated overloading rules.

Then:

```
void func(Foo^ a) { a.bar(); }
```

And what overload will be chosen then? `void bar() &;` or `void bar() &&;`?




>
> >No, you add a new version of it and do not answer how it interacts
> with old ones. Did you ever read how complex is overload resolution in
> C++?
> Read it and add this `^` without breaking it:
>
> >https://en.cppreference.com/w/cpp/language/overload_resolution.html
>
> >here you have some simplified version of it (I do not know how
> accurate it is to standard text but probably a good approximation)
> Could you show in that text where your `T^` will fit?
>
> ***ANSWER***
> 1. For most cases, overload resolution is that tough.
> 2. It will fit right in:
> 1. The reason that I said T^ decays into const T first, if that isn't provided then T, and so on, is to simply the existing rules. Again the rest of the rules remain the same. The decaying hierarchy is to simplify this exact matter.
> >> I said:The answer is that if type_set(selector) were to instantiate into something else(lvalue), the compiler might have had to modify how lvalues work. I want to keep them separate.
>

You did not answer the question, decaying is part of overload
resolution and is suppressed in some contexts.
You can't hand-waving it away as you require to possibility to use
templates with `T^` or there could be conversion available like
`char^` to `int` that need to be handled.
Another example is that `T&` suppress decay, this means you should get
`T^&` type as an argument not `T&`.


> >He asked:again, modify what exactly?
> ****ANSWER****
> Go to "($$$$1.1$$$$)"(control f then enter: ($$$$1.1$$$$) )
>
>
>
>
> On Wed, 8 Apr 2026, 6:59 am Muneem, <itfllow123_at_[hidden]> wrote:
>>
>>
>> Just to get my previous email to proposal list:
>> >I do not know if you know how it will work, you again repeat nearly
>> the same text without addressing the question.
>> You name `T^` as an expression but you use this symbol only as a type
>> of argument of template function, and this is not an expression.
>> Please stop using terms that you do not know what they mean.
>> Besides, why not use there normal `T&`? You break the whole overload
>> resolution, drill hole in value categories for what exactly?
>> Which one should be chosen: `Derived&` or `Base^` overload or opposite
>> `Derivad^` or `Base&`?
>> What is the difference between `T&` and `T^` on assembly level? What
>> can I do with `T^` that is impossible with `T&`?
>> >`type_set` is pointless, it should be same as `decltype(comtainer_obj)`
>> ***ANSWER***
>> 1. I NAMED T^ as in for ever T in the heterogeneous list, but sorry if I didn't convey my point properly.
>> 2. The new value type T^ for every T is important because people may not be comfortable to add certain types in heterogeneous lists, like I may feel uncomfortable to add cookies in my heterogeneous lists because someone might steal them.
>> 3. The new T^ is important because it is what type_set(selector) decays into, If I had said that type_set(selector) decays to a T lvalue or a T xvlaue then that would require some modifications to them which would break the zero overbead principle. Basically the goal was that it should be easy to implement, by making it completely separate. once instantiation is done then only can T^ mix into T&. The goal in short was to not drill a whole by mixing current expression types, but rather make a new one that every implementation can treat for this specific goal of instantion.
>> 4. You asked:
>> >Which one should be chosen: `Derived&` or `Base^` overload or opposite
>> `Derivad^` or `Base&`?
>> Replace Base^ and derived^ with rvalue references and then you know. Basically the overload resolution is the same, it's just another value type.
>> 5. T^ is not different on a assembly level, it just helps user provide overloads for it, and the compiler to instantiate type_set(selector) into it. The mechanics of T^ is implementation defined, In that how type_set(selector) instnatiates into T^ is implementation defined, why?
>> The answer is that if type_set(selector) were to instantiate into something else(lvalue), the compiler might have had to modify how lvalues work. I want to keep them separate.
>> >To recap expresion is `1` or `1 + 2` or `foo()`, something `T&` like
>> in `void foo(T& a)` is some kind of type. Again please do use terms
>> you know what they mean exactly otherwise you will confuse yourself
>> and everyone else who is trying to read your proposal.
>> ***ANSWER***
>> 1. Again, I am sorry for mixing terms, but it's an expression type in a sense that when type_set(selector) object is used then it instnatiates into T^ expression type for a T. When a function takes T^ for some T then it's a object type. The semantics for T^ is the same as lvalues, it's just useful for overloads as I described earlier.
>>
>> On Wed, 8 Apr 2026, 6:11 am Marcin Jaczewski, <marcinjaczewski86_at_[hidden]> wrote:
>>>
>>> śr., 8 kwi 2026 o 02:27 Muneem <itfllow123_at_[hidden]> napisał(a):
>>> >
>>> > >I do not know if you know how it will work, you again repeat nearly
>>> > the same text without addressing the question.
>>> > You name `T^` as an expression but you use this symbol only as a type
>>> > of argument of template function, and this is not an expression.
>>> > Please stop using terms that you do not know what they mean.
>>> > Besides, why not use there normal `T&`? You break the whole overload
>>> > resolution, drill hole in value categories for what exactly?
>>> > Which one should be chosen: `Derived&` or `Base^` overload or opposite
>>> > `Derivad^` or `Base&`?
>>> > What is the difference between `T&` and `T^` on assembly level? What
>>> > can I do with `T^` that is impossible with `T&`?
>>> > >`type_set` is pointless, it should be same as `decltype(comtainer_obj)`
>>> > ***ANSWER***
>>> > 1. I NAMED T^ as in for ever T in the heterogeneous list, but sorry if I didn't convey my point properly.
>>> > 2. The new value type T^ for every T is important because people may not be comfortable to add certain types in heterogeneous lists, like I may feel uncomfortable to add cookies in my heterogeneous lists because someone might steal them.
>>>
>>> What on earth is arguing for "comfortable"?? I ask for technical
>>> reasons why you need things like this and this is not the answer.
>>>
>>> > 3. The new T^ is important because it is what type_set(selector) decays into, If I had said that type_set(selector) decays to a T lvalue or a T xvlaue then that would require some modifications to them which would break the zero overbead principle.
>>>
>>> What modifications?
>>>
>>> > Basically the goal was that it should be easy to implement, by making it completely separate. once instantiation is done then only can T^ mix into T&. The goal in short was to not drill a whole by mixing current expression types, but rather make a new one that every implementation can treat for this specific goal of instantion.
>>>
>>> "easy to implement" no it isn't, adding new value category can be
>>> effective breaking change that will affect every code as for example:
>>>
>>> ```
>>> struct Foo
>>> {
>>> void bar() &;
>>> void bar() &&;
>>> };
>>> ```
>>>
>>> Now its need `void bar() ^;` too.
>>>
>>> > 4. You asked:
>>> > >Which one should be chosen: `Derived&` or `Base^` overload or opposite
>>> > `Derivad^` or `Base&`?
>>> > Replace Base^ and derived^ with rvalue references and then you know. Basically the overload resolution is the same, it's just another value type.
>>>
>>> No, you add a new version of it and do not answer how it interacts
>>> with old ones. Did you ever read how complex is overload resolution in
>>> C++?
>>> Read it and add this `^` without breaking it:
>>>
>>> https://en.cppreference.com/w/cpp/language/overload_resolution.html
>>>
>>> here you have some simplified version of it (I do not know how
>>> accurate it is to standard text but probably a good approximation)
>>> Could you show in that text where your `T^` will fit?
>>>
>>> > 5. T^ is not different on a assembly level, it just helps user provide overloads for it, and the compiler to instantiate type_set(selector) into it. The mechanics of T^ is implementation defined, In that how type_set(selector) instnatiates into T^ is implementation defined, why?
>>> > The answer is that if type_set(selector) were to instantiate into something else(lvalue), the compiler might have had to modify how lvalues work. I want to keep them separate.
>>>
>>> again, modify what exactly?
>>>
>>> > >To recap expresion is `1` or `1 + 2` or `foo()`, something `T&` like
>>> > in `void foo(T& a)` is some kind of type. Again please do use terms
>>> > you know what they mean exactly otherwise you will confuse yourself
>>> > and everyone else who is trying to read your proposal.
>>> > ***ANSWER***
>>> > 1. Again, I am sorry for mixing terms, but it's an expression type in a sense that when type_set(selector) object is used then it instnatiates into T^ expression type for a T. When a function takes T^ for some T then it's a object type. The semantics for T^ is the same as lvalues, it's just useful for overloads as I described earlier.
>>> >
>>> >
>>> > On Tue, 7 Apr 2026, 5:29 pm Marcin Jaczewski, <marcinjaczewski86_at_[hidden]> wrote:
>>> >>
>>> >> wt., 7 kwi 2026 o 05:23 Muneem <itfllow123_at_[hidden]> napisał(a):
>>> >> >
>>> >> > My response Mr.thiago and Mr.Marcin
>>> >> >
>>> >> > Before my response, let me summarize my proposal in the shortest possible words:
>>> >> > A implementation defined container type that holds an object of type "type_set(container_object)". When
>>> >> > ever any type_set(container_object) is used for any container_object of this type, then it instantiates into T^(syntax can be something else for T^). So passing typeset to a function, will call the overload for T^, unless it isn't defined(some other is). T^ is a new expression type that's a subset glvalue, but overloads that use T^ hold a reference to that object. type_set(container_object) is a completelt new expression type, when it decays into T^, the compiler instantiates all code. You may disagree the need for T^, but I think it will help users overload and see it coming.A variable can be of type type_set(comtainer_obj), in which case the user if it will lead to instnatiation. This makes code easy to reason about and deal with.
>>> >> >
>>> >>
>>> >> I do not know if you know how it will work, you again repeat nearly
>>> >> the same text without addressing the question.
>>> >> You name `T^` as an expression but you use this symbol only as a type
>>> >> of argument of template function, and this is not an expression.
>>> >> Please stop using terms that you do not know what they mean.
>>> >> Besides, why not use there normal `T&`? You break the whole overload
>>> >> resolution, drill hole in value categories for what exactly?
>>> >> Which one should be chosen: `Derived&` or `Base^` overload or opposite
>>> >> `Derivad^` or `Base&`?
>>> >> What is the difference between `T&` and `T^` on assembly level? What
>>> >> can I do with `T^` that is impossible with `T&`?
>>> >>
>>> >> `type_set` is pointless, it should be same as `decltype(comtainer_obj)`
>>> >>
>>> >>
>>> >> >
>>> >> > Mr.marcin said:
>>> >> > Then do not use random symbols.
>>> >> > ****ANSWER****
>>> >> > I used random symbols so I don't have to say "the new expression type 2", but if you have any better name, please please tell me to use that.
>>> >> >
>>> >>
>>> >> To recap expresion is `1` or `1 + 2` or `foo()`, something `T&` like
>>> >> in `void foo(T& a)` is some kind of type. Again please do use terms
>>> >> you know what they mean exactly otherwise you will confuse yourself
>>> >> and everyone else who is trying to read your proposal.
>>> >>
>>> >> > Mr.thiagi said:
>>> >> > >This is not about what the community wants. You're the one proposing. You can
>>> >> > incorporate feedback as it comes. But an incomplete proposal will only get us
>>> >> > going around in circles because we don't see the full picture.
>>> >> >
>>> >> > And you need to be familiar with C++ enough to understand that JIT is not
>>> >> > going to be acceptable without our having to say so.
>>> >> >