Date: Fri, 10 Apr 2026 07:38:06 +0200
> On Apr 10, 2026, at 5:03 AM, Muneem via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> It dosent have to cook with water, like it's a new feature.
“Cooking with water” is a metaphor for that your proposal still needs to use the same compiler, the same optimization techniques, and the same hardware. As long as the hardware doesn’t change both your new type and all existing types have the same CPU instructions available. And honestly, the easier the code you write the easier it is for the compiler to optimize. More different optimization strategies will not fit into the time budget that compiler writers put into compilers.
> And the library can't achieve the same thing without breaking existing code, like how are you gonna let the compiler optimizes a variant for std visit without expecting code expecting a normal variant to not work.
I still fail to see any optimizations you are proposing that would not work for existing uses of std::variant. Wouldn’t all uses of std::variant benefit from the optimizations that you propose? Your new type is in general terms still a union/variant/tagged enum. In theory, it can be used in all places a std::variant can be used. How do you teach when to use what? If in the end your new type would effectively replace std::variant, we really should be changing std::variant (at least it is a good name and it’s better to reuse it than to invent a new awkward name). Yes, we hate breaking ABI. But, it has happened with std::string on GCC before (and MSVC used to constantly break ABI with every new version). ABI changes usually don’t break code, but only linking with existing libraries. If there is a good reason (and if it happens rarely) we should break ABIs.
> The solution is a new construct. Like how can you say that the gain is non existent. It's like I can write something similiar to template metaprogramming patterns using macros but should I? Will that be better?
The standard prefers library solutions over new constructs. If with minor changes to the language we can make your proposal work as a library, this is the preferred route. Built-in types should not have any special privileges in C++. A user-defined type should have all the privileges of a built-in type (this is why we have operator overloading). If we adhere to this principle, your new type should be implementable as a library type. If you don’t like this philosophy of C++, choose a different language.
>
> It dosent have to cook with water, like it's a new feature.
“Cooking with water” is a metaphor for that your proposal still needs to use the same compiler, the same optimization techniques, and the same hardware. As long as the hardware doesn’t change both your new type and all existing types have the same CPU instructions available. And honestly, the easier the code you write the easier it is for the compiler to optimize. More different optimization strategies will not fit into the time budget that compiler writers put into compilers.
> And the library can't achieve the same thing without breaking existing code, like how are you gonna let the compiler optimizes a variant for std visit without expecting code expecting a normal variant to not work.
I still fail to see any optimizations you are proposing that would not work for existing uses of std::variant. Wouldn’t all uses of std::variant benefit from the optimizations that you propose? Your new type is in general terms still a union/variant/tagged enum. In theory, it can be used in all places a std::variant can be used. How do you teach when to use what? If in the end your new type would effectively replace std::variant, we really should be changing std::variant (at least it is a good name and it’s better to reuse it than to invent a new awkward name). Yes, we hate breaking ABI. But, it has happened with std::string on GCC before (and MSVC used to constantly break ABI with every new version). ABI changes usually don’t break code, but only linking with existing libraries. If there is a good reason (and if it happens rarely) we should break ABIs.
> The solution is a new construct. Like how can you say that the gain is non existent. It's like I can write something similiar to template metaprogramming patterns using macros but should I? Will that be better?
The standard prefers library solutions over new constructs. If with minor changes to the language we can make your proposal work as a library, this is the preferred route. Built-in types should not have any special privileges in C++. A user-defined type should have all the privileges of a built-in type (this is why we have operator overloading). If we adhere to this principle, your new type should be implementable as a library type. If you don’t like this philosophy of C++, choose a different language.
Received on 2026-04-10 05:38:19