On Sunday, 5 April 2026 18:35:15 Pacific Daylight Time Muneem via Std-Proposals
wrote:
> You are mostly right but with some major details left out:
> 1.the user can overload based of the new expression value type, which
> allows the user to reason better.

You've said that but you haven't explained how this would work.

Is this a concrete, new type with a closed set of possible types it operates
on? If so, how is it different from std::variant?

Or is it a new category like rvalue and lvalue references? If so, is it one
for all the possible types in that closed set? Or is it one per type in that
set? What would the rules be for selecting when overloads with l- and rvalue
references exist? How do they decay to each other, or if at all?

Or do you mean it's an open set, that is, a template?

> 2. This new type can be passed to functions and the compiler will
> instantiate each function that was found in the overload resolution of each
> type for this. Which might sound like std::visit but is much more different:

You're saying "new type", but you'd previously explained it as a category,
like references. See above.

If something gets instantiated, it's a template. So this can't be passed to a
non-template function?

This is not clear at all. Can you give an example of what this overload set
is? Please start simple and then add a few more examples including other
entries to be rejected, and how the selection rules would look like.

> 1.for a compile time index, the compiler gurrenties inlining.

"gurrenties" is not a word. Inlining can never be guaranteed.

Try again.

> 2. The compiler gurrenties that returning a heterogeneous set only leads to
> a pointer move (mechanism is just like exceptions can be captured using
> references for performance).

Are you saying this requires heap allocation? Why are you imposing ABI
requirements on how the return works?

Please describe the observable behaviour (what functions get called) instead
of the mechanism.

> 3. Unlike std::array or vectors of std::variants, the representation of
> this list would be completely up to the compiler, hence the code instnatied
> for each one would be as well.

That's fair, but compilers will need to set it fixed because of ABI. You don't
need to specify what it will be, but it will be fixed.

What do you expect the compilers will do with this freedom?

> 4. Std::visit can only return a variant, while In my case, for any func()
> that you pass an element of the heterogeneous list to, the overload of
> func() chosen for each possible type(of elements in the list) can return:
> 1.T
> 2. Or just that type as T^

A visitation can return anything that it wants to, so long as it's the same
for all types.

But it would be interesting to have a variant transformation that changes each
item to a possible other, and returns that variant.

> In both cases, unless the user casts the return value of func to specific
> value T or T^, you can only assign the return value of func tons variable
> if the variable is variant, unless the index is constexpr, in which case
> you can assign it to T and the compiler will make sure you get an error
> unless the type is correct. If any of the functions return T, then the ones
> returning T^ would be decayed into T or conversely, we could tell the
> compiler to throw an error (upto comcencess). Std::variants can further
> enchance this by allowing the usage of variants of type T^, for each
> std::variant<T^, U^, V^>, this could help function overloads see
> heterogeneous element accesses coming and handle them. T^ for any T is
> gurrentied to be the size of a simple pointer.

"comceness" is not a word. This paragraph made no sense.

> ***Answer***
> Problem isn't solved using virtual functions, for example:
> Base *ptr= new Base{};
> Dereieved obj;
> Obj= virtual_clone(ptr);
> //Slicing so problem is not solved

It is, if the operator= does the right thing. Besides, it's also a moot
problem because most people *don't want* to copy polymorphic objects.

> ***Answer***
> The magic portion is that you can provide overloads specifically for these
> value types T^ that see elements of heterogeneous coming. A even better one
> would be functions accepting std::variants of these T^ or T types. So the
> solution to the magic exists, but to take advantage of it, we need that
> solution to not be constraint by the gurrentied behaviours of current
> container(in order to make them into lists), and to see the elements of
> those heterogeneous coming so we can provide overloads for them.

Write examples of how this syntax would work. Start simple, then build up.

> Basically think of it as the better of both variants and tuples.

I can think of may ways variants and tuples could be better. The question is
whether we are thinking of what you're thinking. You need to be specific.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.