My answer to Mr.Thiago Marciena

>So far, all I've understood is that this is a new syntax for simplifying:
 a) the creation of a std::variant<references, ...>
 b) visitation

That is, if you had:
 std::vector<Foo>
 std::map<Foo, Bar>

You would implicitly declare a
 std::variant<std::vector<Foo> &, std::map<Foo, Bar> &>

populate it with either a runtime or compile time choice

and visit it, calling a function or more in it.

It would be up to the compiler to determine that every use of this type
compiles for every type in the variant.

****answer****
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.
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:
1.for a compile time index, the compiler gurrenties inlining.
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).
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.
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^
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.


>I don't see how you're solving this problem. There are two issues that
cause
object slicing: first, it's the calling of a function to implement it. This
is
easy to do with a virtual function, so a solved problem, but different from
copy/move semantics.

***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


>Second and most importantly: the destination memory area must be of
sufficient
size to accommodate any of the runtime full objects, which by definition
cannot
be known at compile time. You are not addressing this problem. And if you
come
up with a solution for it, then it is also available for the case of
calling a
virtual function.

***Answer***
The destination in this case would either be std::variant or T(if index is
constexpr or a explicit cast specifically for this job is created). The
specific cast job would also be of a massive help to implement this.


>And again: what do virtual functions and object slicing have to do with
anything?

***Answer***
Because it shows virtual functions are incomplete, say you have want a list
of integers, floats, doubles, and you want to do arithmetic, now you have
to use either wrap each in variant, in which case you want pass them to
overloads expecting this specific case. The compiler isn't given a free
hand for the list representation, but rather wrapped in the constraints of
a pre existing container that provides gurrenties that pivoted to other
motivations. In Mr. Steve's case, it was arrays holding "wrapper clases" to
multiple different container type objects. In my case it would be probably
very similar to what I talked about in here:
https://lists.isocpp.org/std-proposals/2026/04/17641.php.


>Same as std::variant then.
***ANSWER***
Not the same as variant for the reasons that talked about in the paragraph
above. Basically a new heterogeneous list would be pivoted towards
representation thats best for itself rather than being in the constraints
of the gurrentied behaviours of some other container. Though there would be
no dynamic allocating what so ever.

>And I don't see how you're solving this problem. This is still the "magic
happens" portion of what you've been trying to convey for a week and it
seems
no one understands.

You seem to be saying that one needs to have an overload for each of the
possible types, but your solution removes this need. How?
***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.

>We don't know if it is type-safe, because we can't tell what the type is
and
how the compiler can reason anything at compile time to prove safety,
because
we don't understand what you're proposing.
***Answer***
1. It is type safe just like std::visit in that everything is produced at
compile time, but also not like solutions based of std::visits:
1. it's not constraint by containers meant used with std::variants.
2. provides more gurrenties like the one I talked about here:
https://lists.isocpp.org/std-proposals/2026/04/17641.php.
3.unlike an array of variants, each element has a fixed type, so you can't
change it. This makes it more type safe and contained, which also makes it
easy to optimize, and provide gurrentied for (constexpr indexes).
4. Because each index has a fixed type, the compiler can further optimize
for that aspect.


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





Regards, Muneem

On Mon, 6 Apr 2026, 4:51 am Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Sunday, 5 April 2026 10:49:34 Pacific Daylight Time Steve Weinrich via
> Std-
> Proposals wrote:
> > He seems to be fixated on a container of some type that returns
> references
> > to different type of containers. For the life of me, I can't figure out
> why
> > this would be needed or how to make it type-safe!
>
> So far, all I've understood is that this is a new syntax for simplifying:
> a) the creation of a std::variant<references, ...>
> b) visitation
>
> That is, if you had:
> std::vector<Foo>
> std::map<Foo, Bar>
>
> You would implicitly declare a
> std::variant<std::vector<Foo> &, std::map<Foo, Bar> &>
>
> populate it with either a runtime or compile time choice
>
> and visit it, calling a function or more in it.
>
> It would be up to the compiler to determine that every use of this type
> compiles for every type in the variant.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>