Date: Fri, 10 Apr 2026 15:55:41 +0500
I want to repeat this line from clang's documentation:
"Optimizer – the part of the compiler responsible for transforming code to
have better performance characteristics without changing the semantics of
how the code behaves."
Basically, you can't optimize the semantics(in my case mechanics), hence
you do need language features at some point.
On Fri, Apr 10, 2026 at 3:28 PM Muneem <itfllow123_at_[hidden]> wrote:
> >I am still trying to understand this part. Let me slightly rephrase my
> example code:
> int^ x = {1,2.5,"C++"}.select(runtime_index); // runtime_index happens to
> be 2
> x = 2;
> How is this compiled? Are there exceptions involved? What should happen if
> the runtime index does not fit the type T^ like in the example?
> ****answer****
> It will throw an expression since its a runtime_index, hence the
> instantiation code runs at runtime, but if it was a compile time index then
> it would be a compiler error, since the instansitation code could be run at
> compile time. A way to implement it would be to provide two blocks of code
> in the definition of select() or operator[]():
> one runs if std::is_constant_evaluated() is true, and the other if false.
> see this:
> https://en.cppreference.com/w/cpp/types/is_constant_evaluated.html .
>
> I think the syntax of defining using {1,2.5,"C++"}.select was bad, and I
> used it for demonstration. a better one would be the same syntax for
> defining tuples:
> std::heterogeneous_llist<Args_t...>{Args_T... args} . especially since the
> container itself is a normal lvalue.
>
> Thanks for your feedback, apreciate it.
>
> On Fri, Apr 10, 2026 at 3:16 PM Simon Schröder via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> On Wed, Apr 8, 2026 at 6:52 PM Simon Schröder <
>> dr.simon.schroeder_at_[hidden]> wrote:
>>
>>>
>>>
>>> > On Apr 8, 2026, at 9:47 AM, Muneem <itfllow123_at_[hidden]> wrote:
>>> >
>>> > int^ x = {1,2.5,”C++”}.select(2); This would throw a huge error at
>>> compile time and is exactly why we need a new expression type T^. Not using
>>> T^ would give too much freedom that could backfire as shown in the example.
>>> In fact for T^, you cant even assign float^ to an int^.
>>>
>>> May bad, I wasn’t clear enough with my example. I do understand that
>>> with index=2 the compiler should use the compile time version and return
>>> the correct type. What my question actually is what would happen if the
>>> index is a runtime index that happens to be 2. How would the code be
>>> compiled to handle this case? What would happen to following source code
>>> lines that use ‘x’? Or would you just throw an exception?
>>>
>>>
>>> I am still trying to understand this part. Let me slightly rephrase my
>> example code:
>> int^ x = {1,2.5,"C++"}.select(runtime_index); // runtime_index happens to
>> be 2
>> x = 2;
>>
>> How is this compiled? Are there exceptions involved? What should happen
>> if the runtime index does not fit the type T^ like in the example?
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
"Optimizer – the part of the compiler responsible for transforming code to
have better performance characteristics without changing the semantics of
how the code behaves."
Basically, you can't optimize the semantics(in my case mechanics), hence
you do need language features at some point.
On Fri, Apr 10, 2026 at 3:28 PM Muneem <itfllow123_at_[hidden]> wrote:
> >I am still trying to understand this part. Let me slightly rephrase my
> example code:
> int^ x = {1,2.5,"C++"}.select(runtime_index); // runtime_index happens to
> be 2
> x = 2;
> How is this compiled? Are there exceptions involved? What should happen if
> the runtime index does not fit the type T^ like in the example?
> ****answer****
> It will throw an expression since its a runtime_index, hence the
> instantiation code runs at runtime, but if it was a compile time index then
> it would be a compiler error, since the instansitation code could be run at
> compile time. A way to implement it would be to provide two blocks of code
> in the definition of select() or operator[]():
> one runs if std::is_constant_evaluated() is true, and the other if false.
> see this:
> https://en.cppreference.com/w/cpp/types/is_constant_evaluated.html .
>
> I think the syntax of defining using {1,2.5,"C++"}.select was bad, and I
> used it for demonstration. a better one would be the same syntax for
> defining tuples:
> std::heterogeneous_llist<Args_t...>{Args_T... args} . especially since the
> container itself is a normal lvalue.
>
> Thanks for your feedback, apreciate it.
>
> On Fri, Apr 10, 2026 at 3:16 PM Simon Schröder via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> On Wed, Apr 8, 2026 at 6:52 PM Simon Schröder <
>> dr.simon.schroeder_at_[hidden]> wrote:
>>
>>>
>>>
>>> > On Apr 8, 2026, at 9:47 AM, Muneem <itfllow123_at_[hidden]> wrote:
>>> >
>>> > int^ x = {1,2.5,”C++”}.select(2); This would throw a huge error at
>>> compile time and is exactly why we need a new expression type T^. Not using
>>> T^ would give too much freedom that could backfire as shown in the example.
>>> In fact for T^, you cant even assign float^ to an int^.
>>>
>>> May bad, I wasn’t clear enough with my example. I do understand that
>>> with index=2 the compiler should use the compile time version and return
>>> the correct type. What my question actually is what would happen if the
>>> index is a runtime index that happens to be 2. How would the code be
>>> compiled to handle this case? What would happen to following source code
>>> lines that use ‘x’? Or would you just throw an exception?
>>>
>>>
>>> I am still trying to understand this part. Let me slightly rephrase my
>> example code:
>> int^ x = {1,2.5,"C++"}.select(runtime_index); // runtime_index happens to
>> be 2
>> x = 2;
>>
>> How is this compiled? Are there exceptions involved? What should happen
>> if the runtime index does not fit the type T^ like in the example?
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
Received on 2026-04-10 10:55:59
