In short:
The argument that "the compiler obeys the programmer" assumes the
programmer has the right tools to express their intent. Currently, if I
want a fast, type safe, dynamically indexed container, I have to to do all
that using metaprogramming tools that weren't built for that.
My point isn't that the compiler should ignore the programmer's choice of
std::map; it's that C++ lacks a language lebel facility for strict dynamic
typing that allows the compiler to optimize the dispatch as efficiently as
it optimizes a function call or a template instantiation. We shouldn't have
to choose between "Statically Rigid" and "Manually Dangerous". In my
code(the cost I posted before), I forgot to provide assignment operator for
the first element type in the set.

On Fri, 10 Apr 2026, 10:19 am Muneem, <itfllow123_at_[hidden]> wrote:

> 1. I did not say tuple has book keeping data, never claimed that, but
> sorry if I had implied that. Like my point was that tuple's current book
> keeping data(none or maybe In some implementations some) is not meant for
> runtime indexing.
> 2. Reflectors are an extension of metaprogramming, NOT for dynamic typing.
> Metaprogramming can help you with compile time duck typing and even
> constraint it, but dynamic typing is a separate domain and requires proper
> language support to be done efficiently.
> 3. Even if you extended reflectors or tuples or anything to allow runtime
> indexing then that construct/facility isnt that anymore. Once you change or
> extend an existing METAPROGRAMMING facility to dynamic typing, then that
> facility dosent exist anymore.
> 4. I was trying to explain that in some cases, the programmer dosent know
> what he wants. Dynamic typing is that, it's extremely hard to reason with
> dynamic typing without language facilities. C++ has zero facilities for
> strict dynamic typing. The fact that the compiler can't optimize maps into
> flat maps is my point
> T that in some cases/usecases, it may be faster hence the compiler can't
> optimize it without breaking ABI's that expect those cases.
> 5. Dynamically typed containers is different then statically typed
> containers, since your problem isn't how it looks under the hood, but
> rather if it's even type safe and if it's fast enough because the current
> metaprogramming facilities that help us translate runtime tags into
> template dispatches are not type safe. Like do you ever ask yourself
> weather a variant gives you enough control when you use visit? Why not?
> Because you know the compiler can do it better than you. In my case, I
> want it to be like that but TYPE SAFE.
>
>
> On Fri, 10 Apr 2026, 10:10 am Simon Schröder, <
> dr.simon.schroeder_at_[hidden]> wrote:
>
>>
>>
>> > On Apr 10, 2026, at 3:17 AM, Muneem via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>> >
>> > Again, why do flat maps exist, why don't we all optimize maps away if
>> the compiler can figure out that the constant latency of a flat maps is
>> actually gonna be faster.
>>
>> Regular maps exist because the performance gap between memory and CPU
>> used to be a lot less when they were invented. And there are probably a lot
>> of different microprocessors where a regular map is still faster than a
>> flat map.
>>
>> Why don’t compilers optimize every map into a flat map? Because the
>> compiler still does exactly what the programmer tells it to do. If the
>> programmer decides he wants a regular map he will get one. I hope the
>> compiler will always obey the programmer!
>
>