If you feel like there are any holes in the narrative then propose a
proposal on how to fix the issue with intent. I really really want to
hear from you.
regards, Muneem

On Fri, Apr 3, 2026 at 3:26 AM Muneem <itfllow123_at_[hidden]> wrote:

> while this feature might seem like a new syntaxical construct, it isn't.
> refer to constexpr if statements (if statements that depended on
> constexpr could always have been computed at compile time), but constexpr
> if statements explicitly stops you from using non constexpr expressions in
> the if statement. Why was consteval added when constexpr existed? Why can
> you fold variadic templates? The list goes on and on. In particular, this
> syntax would infer to the compiler that the compiler can use any
> bookkeeping or alignment information that it wants. The alignments is what
> it will retain from structs, while bookkeeping would be a new thing. No one
> complains about alignments in structs but we all do complain of the
> potential overhead that a feature that is completely optional would have.
> why does no one complain about the overhead in std::visit? because its
> optional to use, it wont break ABI stability until you change the
> corrosponding std::variant.
>
> Thank you for your feedback!
> regards, Muneem.
>
> On Fri, Apr 3, 2026 at 3:18 AM Muneem <itfllow123_at_[hidden]> wrote:
>
>> I am not in any way changing the language; what I am doing is adding
>> constructs to increase clarity for both programmers and compilers. This
>> would at the very least lead to readable code than the current state where
>> code using std::visit or switch case is ugly, and would (probably) lead to
>> lower compiler time for compilers that try to optimize these branches.
>>
>> On Fri, Apr 3, 2026 at 3:15 AM Muneem <itfllow123_at_[hidden]> wrote:
>>
>>> I completely agree with you, that's why I think a new construct would be
>>> better, not only for being less verbose than switch statements but also
>>> providing the some intent that subscripting does. I provided benchmarks
>>> because that is what some asked for. Ask me anything, and I would be
>>> pleased to respond!
>>> regards, Muneem
>>>
>>> On Fri, Apr 3, 2026 at 3:12 AM Muneem <itfllow123_at_[hidden]> wrote:
>>>
>>>> Hi, again!
>>>> > Interesting compiler veven remove all warpers and only emit calls to
>>>> `std::cout`
>>>> In my benchmark, I used std::cin and volatile x to make sure that any
>>>> compile time indexing dosent happen!
>>>> I completely agree with your point on cache locality, infact, that's
>>>> the whole point of the construct, so the compiler has as much context as
>>>> possible so it can make code cache locale. I know benchmarks can lie, but
>>>> assembly lies more because compilers can produce the same assembly for two
>>>> functions that are only slightly slower, but small differences can have
>>>> huge implications on cache performance. I completely agree with you that
>>>> cache performance matters more than anything, and my example shows that the
>>>> compiler has context and intent that I want a contiguous allocated
>>>> structure that I can index through. Functions calls are worse because they
>>>> dont speak enough intent and not enough context, meanwhile my proposal will
>>>> give you context from many sources and the clearest intent.
>>>>
>>>> These intent based constructs are useful so that the compiler can do
>>>> exactly what you said "deal with cache better". Benchmarks show that even
>>>> in small code, compilers fall short when it comes to optimizing switch case
>>>> statements and std::visits. Benchmarks can lie, but in my case it shows
>>>> that if we have proper syntax constructs for these features, then we can in
>>>> fact make it cache friendly because the compiler has the exact map of
>>>> intent and context. It can basically measure a lot to increase performance.
>>>>
>>>> thanks again for your feedback
>>>>
>>>> regards, Muneem
>>>>
>>>> On Fri, Apr 3, 2026 at 2:57 AM Marcin Jaczewski <
>>>> marcinjaczewski86_at_[hidden]> wrote:
>>>>
>>>>> Benchmarks do lie...
>>>>>
>>>>> The first rule of benchmarking is not testing real code and this
>>>>> creates biases that screw
>>>>> results, considering simple things like CPU cache. Benchmark can
>>>>> easily fill it full and run at 100% speed.
>>>>> but in real code the same logic has only 0.1% cache available to it as
>>>>> other code needs the same cache too.
>>>>> If you have cache miss, the whole code run 100 times slower.
>>>>>
>>>>> Only test final optimized assembly are true test of permanence,
>>>>> benchmarks are only hits for searching optimal solutions.
>>>>>
>>>>>
>>>>> And for your example, why not simply use get function pointer like
>>>>> `&A::f` and that call this function directly?
>>>>> Why bother with indexes?
>>>>>
>>>>> ```
>>>>> #include <iostream>
>>>>> #include <tuple>
>>>>> #include <functional>
>>>>>
>>>>> struct A { int get() { return 10; } };
>>>>> struct B { double get() { return 1; } };
>>>>> struct C { float get() { return 2.1; } };
>>>>>
>>>>> template<typename C>
>>>>> struct GetCallerArg;
>>>>> template<typename T, typename R>
>>>>> struct GetCallerArg<R (T::*)()>
>>>>> {
>>>>> using type = T;
>>>>> };
>>>>>
>>>>> template<typename T, auto Callback>
>>>>> void warper(T& a)
>>>>> {
>>>>> std::cout<< std::invoke(
>>>>> Callback,
>>>>> std::get<typename GetCallerArg<decltype(Callback)>::type>(a)
>>>>> ) << '\n';
>>>>> }
>>>>> template<typename T>
>>>>> using Access = void(*)(T&);
>>>>>
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>> std::tuple<A,B,C> t{ A{}, B{}, C{} };
>>>>>
>>>>> Access<decltype(t)> f = &warper<decltype(t), &A::get>;
>>>>>
>>>>> f(t);
>>>>>
>>>>> f = &warper<decltype(t), &B::get>;
>>>>>
>>>>> f(t);
>>>>> }
>>>>> ```
>>>>> https://godbolt.org/z/Y5fGEMdc4
>>>>>
>>>>> Intresing compiler veven remove all warpers and only emit calls to
>>>>> `std::cout`
>>>>>
>>>>> czw., 2 kwi 2026 o 23:20 Muneem via Std-Proposals
>>>>> <std-proposals_at_[hidden]> napisał(a):
>>>>> >
>>>>> > benchmarks don't lie! Even if the assembly is the same size and
>>>>> looks similar, benchmarks show otherwise. Do benchmarking in the code that
>>>>> I showed using my proposal.
>>>>> > --
>>>>> > Std-Proposals mailing list
>>>>> > Std-Proposals_at_[hidden]
>>>>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>>