I get the "C++ is so full of nonsense, and they keep adding more of it!" attitude, and I largely agree with it, but "auto" is a bad target. auto makes a lot of c++ code (most, arguably) much easier to read and cleans up and simplifies a lot of the language. Like, the fact that you never, ever, have to write out the full name of iterator types in C++ (you can just go "auto it = vec.begin()" or whatever) is worth the feature all on its own. It also makes dealing with complex generics simpler. It's a huge quality of life improvement.

There's a reason most languages have added type inference, and it's not just a trendy bandwagon. In most reasonably recent languages (Rust and Swift notably), it is in fact the default to do this kind of type inference. It's genuinely a nicer way to program.

In C++ it also serves another important purpose: if there wasn't auto, there wouldn't be lambdas. All lambdas in C++ have an type created by the compiler which you can't access the name of. In order to store a lambda in its native type, you therefore have to use auto. Basically, if you like that C++ is becoming "more functional", that is only really possible because of adding auto.

I've come back to C++ after being away from it for a few years, and modern C++ (17, 20) is a delight to work with compared to what we had in the 90s. RAII especially...

I was happily taking advantage of it in Turbo C++ 1.0 for MS-DOS.

    auto sqr = [](double val) { return val * val; };

How would you use decltype here?

It's been proposed already. One of the issues with the proposal that jumps out to me is that it wants memory allocation to be not allowed in a pure function. Which is both fair & not. That means no collections, more or less, as you can't allocate the return value.

But if you allow memory allocations, then you go down the rabbit hole of well whose memory allocations are allowed? Only `new`? What about `malloc`? Or a custom allocator? If custom allocators are allowed, do they need a `mutable` keyword equivalent but for pure functions, where it's internally not-pure but is allowed to be used from a pure function?

But it looks like there was no follow-up proposal. `constexpr` isn't too far off from a [[pure]] specifier, though.

Because there's no ecosystem of pure functions, a single impure function in the transitive closure of your dependencies can ruin your day. (Unless you depend on no code written by other people.)

Compare with haskell, where effects are enumerated and purity is the default: most functions are pure.

Yeah that is me. I can certainly see how a program that uses a lot of libraries would have issues with pure though. Not sure what the solution to that would be other than going full haskell mode, which isn't what people who use C++/D would want anyways