> So, my first proposal is to have a template library that can operate
> using pointers and arrays without extra templated abstraction layers.
> Then the compiler does a better job, your compiler errors are nice and
> clean and the debugger is a relative joy to use. And when it comes to
> safety, the clang sanitizers can be used to make raw pointers just as
> safe as iterators these days.

We already have that in some sense. You can pass pointers directly
into standard library algorithms and disable every possible assertion
that would have run by default.

Also, I'm not sure what settings you've used to get that "bad"
assembly output, but both GCC and Clang with -O3 and -std=c++23 output

"example1()":
        mov edx, 3
        mov esi, 7
        mov edi, OFFSET FLAT:.LC0
        xor eax, eax
        jmp "printf"

... for the std::sort case. https://godbolt.org/z/EvP6szbWd I was able
to get the bad output you're describing only without a -std flag.

Even if it wasn't possible to get this "good" output here, eyeballing
performance by looking at assembly is a terrible habit. You should
actually benchmark the code instead of cherry-picking a bad assembly
snippet and declaring we have to overhaul the standard library so you
won't get that bad snippet again. Most of these obvious bad codegens
can likely be resolved by submitting a bug report or better yet,
contributing to your standard library of choice.

> If that seems unnecessary because the compiler should be up to the
> task at hand then please consider my second proposal. Why don't we
> have a way to convince the compiler to do what we are telling everyone
> it does? I have seen a professionally written C++ codebase spend 3% of
> its time inside std::vector::operator[] with all optimizations turned
> on. (This is why the standard library gets banned from real-time
> embedded projects.) If we required support for -O9 and told everyone
> they may have to let the compiler run overnight then at least all this
> talk about what is possible with compile time evaluation would be less
> deceptive.

You can manually specify more aggressive optimizations such as
increased inlining threshold for various compilers. What you're
describing seems like you want additional compiler flags, or maybe
just need to read your compiler's manual. There is nothing to propose
here.