How well do you know C++ auto type deduction?

Strong agree here. It's not just because it reduces cognitive load, it's because explicit types allows and requires the compiler to check your work.

Even if this isn't a problem when the code is first written, it's a nice safety belt for when someone does a refactor 6-12 months (or even 5+ years) down the road that changes a type. With auto, in the best case you might end up with 100+ lines of unintelligible error messages. In the worst case the compiler just trudges on and you have some subtle semantic breakage that takes weeks or months to chase down.

The only exceptions I like are iterators (whose types are a pita in C++), and lambda types, where you sometimes don't have any other good options because you can't afford the dynamic dispatch of std::function.

        const auto start = std::chrono::steady_clock::now();
        do_some_work(size);
        const auto end = std::chrono::steady_clock::now();
        const std::chrono::duration<double> diff = end - start;

        std::cout << "diff = " << diff << "; size = " << size << '\n';

I also prefer not to use auto when getting iterators from STL containers. Often I use a typedef for most STL containers that I use. The one can write MyNiceContainerType::iterator.

So for example I'd write:

  var x = new List<Foo>();

  List<Foo> x = new List<Foo>();

Whereas I'd write:

  List<Foo> x = FooBarService.GetMyThings();

Although with newer language features you can also write:

  List<Foo> x = new();

auto it = some_container.begin();

Not even once have I wished to know the actual type of the iterator.

IDEs are an invention from the late 1970's, early 1980's.

For example:

auto a;

will always fail to compile not matter what flags.

int a;

is valid.

Also it prevents implicit type conversions, what you get as type on auto is the type you put at the right.

That's good.

In both Rust and C++ we need this because we have unnameable types, so if their type can't be inferred (in C++ deduced) we can't use these types at all.

In both languages all the lambdas are unnameable and in Rust all the functions are too (C++ doesn't have a type for functions themselves only for function pointers and we can name a function pointer type in either language)

Type inference is usually reserved for more general algorithms that can inspect not only how a variable is initialized, but how the variable used, such as what functions it's passed into, etc...

https://news.ycombinator.com/item?id=11604474

95%[1] of the time, deduction is enough, but occasionally you really wish you had proper inference.

[1] percentage made up on the spot.

For any seriously templated or metaprogrammed code nowadays a concept/requires is going to make it a lot more obvious what your code is actually doing and give you actually useful errors in the event someone is misusing your code.

Most of the "ugly" of these examples only really matters for library authors and even then most of the time you'd be hard pressed to put yourself in these situations. Otherwise it "just works".

Basically any adherence to a modicum of best practices avoids the bulk of the warts that come with type deduction or at worst reduces them to a compile error.

And lifetime specifiers can be jarring. You have to think about how the function will be used at the declaration site. For example usually a function which takes two string views require different lifetimes, but maybe at call site you would only need one. It is just more verbose.

C++ has a host of complexities that come with header/source splits, janky stdlib improvements like lock_guard vs scoped_lock, quirky old syntax like virtual = 0, a lack of build systems and package managers.