It's ironic that the STL basically exists for stable sort (that's what Alex Stepanov was trying to create an efficient version of which led to most of the standard algorithms as building blocks), yet it's apparently not had much optimization focus in this standard library implementation.
I think a better approach might be automated performance regression tests. That's checking the property you probably actually care about directly (performance) and leaves the compiler (and other engineers) some leeway to do better without breaking the test.
Actually setting up a robust system for perf regression tests is tricky though...
The disconnect is weird isn't it? The latest coding models can churn out a lot of mediocre code that more or less works if the task is sufficiently well specified, but it's not particularly good code, they have no real taste, no instinct for elegance or simplification, weak high level design. It's useful, but not anywhere near superhuman. It's also my impression that improvements in raw intelligence, far from increasing exponentially, are plateauing. The advances that people are excited about come from agentic patterns and tool use, but it's not much higher levels of intelligence, just slightly better intelligence run in a loop with feedback. Again that's useful but it's nowhere in the realms of "greater than Nobel winning across all domains".
Outside of coding, the top models still fall flat on their face when faced with relatively simple knowledge work. I got completely bogus info on a fairly simple tax question just a few days ago for example, and anyone using AI regularly with any discernment runs into simple failures like this all the time. It's still useful but the idea that we're on some trajectory to exceeding top human performance across all domains seems completely unrealistic when I look at my experience of how things have actually been progressing.
Minor correction though, I think this is not quite correct:
> The compiler computes the required size at compile time by summing the sizes of all locals (accounting for alignment).
In optimized C++ builds, compilers can reuse stack storage for locals whose live ranges don’t overlap, so the required stack frame size is not necessarily the sum of all locals. Some locals may never have stack storage at all (e.g. living entirely in registers or being optimized away).
For objects with non-trivial destructors, storage reuse is constrained by object lifetime and destruction semantics, but the same stack slot may still be reused after the destructor has run.
This might be true in the abstract but it's not true of actual compilers dealing with real world calling conventions. Absent inlining or whole program optimization, calling conventions across translation units don't leave much room for flexibility.
The semantics of pass by const reference are also not exactly the same as pass by value in C++. The compiler can't in general assume a const reference doesn't alias other arguments or global variables and so has to be more conservative with certain optimizations than with pass by value.
This looks cool, I find myself wishing for a language and introductory tutorial that isn't so targeted at Python programmes however (though I understand from a commercial point of view why that may make sense).
It seems like this is actually an elegant typed functional language but the Python syntax looks ugly and verbose and like it's trying to hide that compared to something more ML/F# or Haskell inspired.
I'll try and get past that though as it does look like there's something pretty interesting here.
> 42.9 units of insulin from a single photo. That’s not a rounding error. That’s a potential fatality.