Date: Mon, 6 Apr 2026 14:39:51 +0500
Hi!
Thanks for your feedbacks ❤️❤️❤️
I will answer Mr.thiago ( I can't respond to Mr.simon now because I have to
go to sleep, but I really want to and I will)
Sorry for my late response ( I was showering and then washed my clothes, so
it took some times)
***Note**
My proposal was trying to normalize extreme solutions, so I didn't explain
exactly what I wanted to slowly propose some solutions, you guys will find
issues, and I will propose more extreme solutions on the way, so as to show
why extreme solutions are important.
******$$CURRENT_SOLUTION$$*****
There would now be 2 new expression value types and one type included by
this proposal:
1. Every object in the list would be of an expression value called
type_set(selector). Typeset in this case is a operator that returns a
unique type for every selector, so you cant assign an object thatd
potentially from one selector into another, without it decaying to T^
first. This is important because the homogenous itself is compile time
fixed (the types at each index are fixed), so any mistake should lead to an
exception and if the index used was constexpr then a compiler error. This
simplified the notion of handling errors and type safety by providing a
intermediary type to handle code generation, all the potential gurrenties,
compile time errors, and exceptions.
Std::variant fails at this because not only if is verbose ( I know you guys
don't care, so really sorry), but I enforcing fixed types in each index is
automated as well, which of course no container can provide, doing such
checks with tuples used with " for templates " would as you can imagine be
tiresome and hard to reason about. Tuple fails because tuples have fixed
types that can't be checked at compile time, so basically
selector(index)=selector(index) would compile but only throw if type didn't
match at runtime. If the indexes are constexpr and it didn't match then
compiler is to issue a diagnostic message.
2. A T^, that this type can decay into, and for which the user can provide
overloads for.
The implementation for this 1 expression value type decaying into T^
remains the same: https://lists.isocpp.org/std-proposals/2026/04/17640.php
(got to the implementation part))
When ever this
3. The heregenous list itself.
The heterogeneous would be a new container(implementation)or std::array of
the new type_set(selector) expression type. As I said, each index would
have fixed types, but I also want to add that assigning from one
heterogeneous list to another is not allowed(a diagnostic message would be
issued), to promote safer code practices.
>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?
******ANSWER******
1. T^ is a new expression type and references to T^ can be overloaded using
T^ as type. type_set(selector) always decays to T^ (the implementation of
which could like in this email:
https://lists.isocpp.org/std-proposals/2026/04/17640.php). when passed to a
function or when it member function of it is called, the actual branching
for all possible decayed T^'s would be at runtime, but the function
overloads called or the member function called are decided at compile time
for each T^.
>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.
****ANSWER****
1. I am sorry to get the terms mixed, but they are new expression value
types or a category.
2. I am also sorry for my initial introduction of a T^ to be incomplete,
but now with type_set(selector), the compiler would branch for every T^
that itself can decay into T. So that every funciton can be overloaded for
T^.
****Example of how this would work out****
{1, obj2, "Intel goated"}selector(index);
Template<typename T>
Int func(T^ obj){
//A lot of other code and stuff, and the declaration of container X
X.push_back(std::move(obj); //you can actually copy and move things, unlike
type with virtual functions that make the risk of slicing hard for you to
reason with your code.
//This function also saw T^ coming hence can do specific actions only for
T^ (for example to make sure the user is allowed to use a specific type
through a heterogeneous lists(type should only be accessed by, say: only
someone who gives the right input(from say cin)can access, else a exception)
Return 0;
}
Int func(std::string a){
return a.lenght();//int is in type_set(selector) so it works
}
Int a = func(selector(2));//assignment worked
Int a= func(selector(runtime_index))// fails
type_set(selector) B_var= func(selector(runtime_index));//Works
//Note again:decaying of B_var into T^ would lead to instnatiation, but
decaying of T^ to anything else won't.
For all func() chosen the return type must be within "selector" for this
line to not result into a compile time errors:
type_set(selector) B_var= func(selector(runtime_index));
If the return type of any func() was not in
Selecter then we have to issue a diagnostic message.
You can also assign selector(index) directly, but the rules remain the same
as above.
"gurrenties" is not a word. Inlining can never be guaranteed.
****ANSWER****
By gurrentied inlining, I meant that because the type is known at compile
time hence it should be gurrentied that no branching is to be done, so as
to inline the branch. I am sorry for using inline outside the bounds of
what the standard defines it as, I just have a habit of using c++ terms as
vocabulary.
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.
****ANSWER****
1. No, it won't require heap allocation. The reason I stated was because
exceptions can already capture objects thrown by value by reference(
https://blog.knatten.org/2010/04/02/always-catch-exceptions-by-reference/#:~:text=On%20the%20left%20side%20is,catching%20is%20not%20very%20polite.),
so the compiler can use those mechanisms to optimize this if the book
keeping information required to implement such a list is too much.
What do you expect the compilers will do with this freedom(Mr.thiago is
taking about the freedom of compilers to choose any representation of the
heterogeneous list)?
****ANSWER****
1. It can as I said make it so that returning acts the same as throwing an
exception (if it wants add a lot book keeping information)
2.it can compute both the index of the common types and the branch together
and not have store them separately(a potential technique for this is in
this email to Mr.simon:
https://lists.isocpp.org/std-proposals/2026/04/17640.php (go to the value
representation part).
3. If it uses vtables, then it can store them close to the sequence of
objects for each type.
>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.
****Answer****
1. That's the issue, it can only return one type.
2. Yes, and my next expression type "type_set(selector)" would help with
that, and make it more type safe.
"comceness" is not a word. This paragraph made no sense.(Mr.Thiago's
response to a paragraph trying to make up for the absence of
type_set(selector).)
****ANSWER****
1. I know:
1. I was missing the missing puzzle and was too scared to propose it
"(type_set(selector) is the missing puzzle". I was scared because I was
trying to take this proposal step by step, by normalizing radical features
as we go, and so I can know the semantics and possible implementations of
those (base on what I think you guys would like after talking to you).
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****
1. That's the point, polymorphic objects are an incomplete solution to
everything. Like most people use it:
1. They have a single interface to multiple objects (similiar to
std::variant but without the space overhead of unions).
2. To not have to recompile the code that depends on it whenever any of the
objects change (since the objects(in OOP patterns) are allocated at
runtime).
The goal almost never is to provide a list of heterogeneous objects that
can be moved, copied, or delth with as normal objects , while provind
special overloads for special cases to treat them specially.
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.
****ANSWER****
1. I am thinking of a new container(should implementation defined) or
(should not be) std::array of the value type type_set(selector). The goal
is to provide safety as I discussed:
1.Decaying into T^ allowing overloads for T^ to see if the user should even
have access or to provide optimizations.
2. Variant like behaviour but each index has a fixed type, and unlike
tuple, select(runtime_index)= select(runtime_index).
On Mon, 6 Apr 2026, 10:29 am Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Thanks for your feedbacks ❤️❤️❤️
I will answer Mr.thiago ( I can't respond to Mr.simon now because I have to
go to sleep, but I really want to and I will)
Sorry for my late response ( I was showering and then washed my clothes, so
it took some times)
***Note**
My proposal was trying to normalize extreme solutions, so I didn't explain
exactly what I wanted to slowly propose some solutions, you guys will find
issues, and I will propose more extreme solutions on the way, so as to show
why extreme solutions are important.
******$$CURRENT_SOLUTION$$*****
There would now be 2 new expression value types and one type included by
this proposal:
1. Every object in the list would be of an expression value called
type_set(selector). Typeset in this case is a operator that returns a
unique type for every selector, so you cant assign an object thatd
potentially from one selector into another, without it decaying to T^
first. This is important because the homogenous itself is compile time
fixed (the types at each index are fixed), so any mistake should lead to an
exception and if the index used was constexpr then a compiler error. This
simplified the notion of handling errors and type safety by providing a
intermediary type to handle code generation, all the potential gurrenties,
compile time errors, and exceptions.
Std::variant fails at this because not only if is verbose ( I know you guys
don't care, so really sorry), but I enforcing fixed types in each index is
automated as well, which of course no container can provide, doing such
checks with tuples used with " for templates " would as you can imagine be
tiresome and hard to reason about. Tuple fails because tuples have fixed
types that can't be checked at compile time, so basically
selector(index)=selector(index) would compile but only throw if type didn't
match at runtime. If the indexes are constexpr and it didn't match then
compiler is to issue a diagnostic message.
2. A T^, that this type can decay into, and for which the user can provide
overloads for.
The implementation for this 1 expression value type decaying into T^
remains the same: https://lists.isocpp.org/std-proposals/2026/04/17640.php
(got to the implementation part))
When ever this
3. The heregenous list itself.
The heterogeneous would be a new container(implementation)or std::array of
the new type_set(selector) expression type. As I said, each index would
have fixed types, but I also want to add that assigning from one
heterogeneous list to another is not allowed(a diagnostic message would be
issued), to promote safer code practices.
>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?
******ANSWER******
1. T^ is a new expression type and references to T^ can be overloaded using
T^ as type. type_set(selector) always decays to T^ (the implementation of
which could like in this email:
https://lists.isocpp.org/std-proposals/2026/04/17640.php). when passed to a
function or when it member function of it is called, the actual branching
for all possible decayed T^'s would be at runtime, but the function
overloads called or the member function called are decided at compile time
for each T^.
>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.
****ANSWER****
1. I am sorry to get the terms mixed, but they are new expression value
types or a category.
2. I am also sorry for my initial introduction of a T^ to be incomplete,
but now with type_set(selector), the compiler would branch for every T^
that itself can decay into T. So that every funciton can be overloaded for
T^.
****Example of how this would work out****
{1, obj2, "Intel goated"}selector(index);
Template<typename T>
Int func(T^ obj){
//A lot of other code and stuff, and the declaration of container X
X.push_back(std::move(obj); //you can actually copy and move things, unlike
type with virtual functions that make the risk of slicing hard for you to
reason with your code.
//This function also saw T^ coming hence can do specific actions only for
T^ (for example to make sure the user is allowed to use a specific type
through a heterogeneous lists(type should only be accessed by, say: only
someone who gives the right input(from say cin)can access, else a exception)
Return 0;
}
Int func(std::string a){
return a.lenght();//int is in type_set(selector) so it works
}
Int a = func(selector(2));//assignment worked
Int a= func(selector(runtime_index))// fails
type_set(selector) B_var= func(selector(runtime_index));//Works
//Note again:decaying of B_var into T^ would lead to instnatiation, but
decaying of T^ to anything else won't.
For all func() chosen the return type must be within "selector" for this
line to not result into a compile time errors:
type_set(selector) B_var= func(selector(runtime_index));
If the return type of any func() was not in
Selecter then we have to issue a diagnostic message.
You can also assign selector(index) directly, but the rules remain the same
as above.
"gurrenties" is not a word. Inlining can never be guaranteed.
****ANSWER****
By gurrentied inlining, I meant that because the type is known at compile
time hence it should be gurrentied that no branching is to be done, so as
to inline the branch. I am sorry for using inline outside the bounds of
what the standard defines it as, I just have a habit of using c++ terms as
vocabulary.
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.
****ANSWER****
1. No, it won't require heap allocation. The reason I stated was because
exceptions can already capture objects thrown by value by reference(
https://blog.knatten.org/2010/04/02/always-catch-exceptions-by-reference/#:~:text=On%20the%20left%20side%20is,catching%20is%20not%20very%20polite.),
so the compiler can use those mechanisms to optimize this if the book
keeping information required to implement such a list is too much.
What do you expect the compilers will do with this freedom(Mr.thiago is
taking about the freedom of compilers to choose any representation of the
heterogeneous list)?
****ANSWER****
1. It can as I said make it so that returning acts the same as throwing an
exception (if it wants add a lot book keeping information)
2.it can compute both the index of the common types and the branch together
and not have store them separately(a potential technique for this is in
this email to Mr.simon:
https://lists.isocpp.org/std-proposals/2026/04/17640.php (go to the value
representation part).
3. If it uses vtables, then it can store them close to the sequence of
objects for each type.
>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.
****Answer****
1. That's the issue, it can only return one type.
2. Yes, and my next expression type "type_set(selector)" would help with
that, and make it more type safe.
"comceness" is not a word. This paragraph made no sense.(Mr.Thiago's
response to a paragraph trying to make up for the absence of
type_set(selector).)
****ANSWER****
1. I know:
1. I was missing the missing puzzle and was too scared to propose it
"(type_set(selector) is the missing puzzle". I was scared because I was
trying to take this proposal step by step, by normalizing radical features
as we go, and so I can know the semantics and possible implementations of
those (base on what I think you guys would like after talking to you).
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****
1. That's the point, polymorphic objects are an incomplete solution to
everything. Like most people use it:
1. They have a single interface to multiple objects (similiar to
std::variant but without the space overhead of unions).
2. To not have to recompile the code that depends on it whenever any of the
objects change (since the objects(in OOP patterns) are allocated at
runtime).
The goal almost never is to provide a list of heterogeneous objects that
can be moved, copied, or delth with as normal objects , while provind
special overloads for special cases to treat them specially.
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.
****ANSWER****
1. I am thinking of a new container(should implementation defined) or
(should not be) std::array of the value type type_set(selector). The goal
is to provide safety as I discussed:
1.Decaying into T^ allowing overloads for T^ to see if the user should even
have access or to provide optimizations.
2. Variant like behaviour but each index has a fixed type, and unlike
tuple, select(runtime_index)= select(runtime_index).
On Mon, 6 Apr 2026, 10:29 am Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2026-04-06 09:40:12