Hard disagree. There are times when nobody, really nobody, cares about a given type. See the example of std::chrono::steady_clock::now over at cppreference.com. There you have

        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';

> Usually codebases disallow auto because without an IDE it's difficult to see the type. I think this reduces the cognitive load of C++ a bit. The only time it is allowed is getting iterators types from STL containers.

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.

There are unspeakble types, such as lambdas, that are not exactly easy to handle without "auto". How a variable containing local lambda with captures will look without "auto"?

I know Google’s styleguide discourages auto, but other C++ places I’ve worked weren’t scared of it. The type deduction rules usually do what I expect, unless I have a weird pre-C++11 proxy type that somehow hasn’t been updated in the last 14 years.

It depends. If you write your code based on abstractions/class features, does it matter ehat type it is? If I call calculation->execute() I don't care what type of object calculation is as long as it can execute and returns something that'll I'll use later for other purpose. To me auto in this case is something similar to using pointers to a base class, but even more abstract

I agree that auto should be used as little as possible. There are good uses, though. It is okay to use when the type is trivially inferred from the code. What is auto in "auto ptr = std::make_shared<MyNiceType>();". Everybody who knows any C++ knows. Also, lambdas do not have a type that can be written down, so it is okay to use auto for them.

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.

I use auto everywhere. It makes code a lot more maintainable and easy to reason about in my view.

> Usually codebases disallow auto because without an IDE it's difficult to see the type.

Really? I've never experienced this myself.

The guidelines I follow for C# has "use var where it's obvious, but explicitly type when not".

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();

I came to like auto over the years, although I also use it sparingly. Sometimes the concrete types only add visual noise and not much helpful information, e.g. iterators:

auto it = some_container.begin();

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

That is like saying that one rather make fire with sticks and stones than with a lighter, because otherwise one would be lost when going out camping.

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

auto has a good perk, it prevents uninitialized values (Which is a source of bugs).

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.

It’s extremely convenient for certain things. For example, let’s say I’m referring to an enum constant field of a deeply-nested type. This can easily be expressed as “auto k = a.b.c.d.kind” instead of “Alpha::Bet::Charlie::Delta::Kinds k = a.b.c.d.kind”. It should be used sparingly in local contexts where the meaning cannot be confusing.

Odd, it's not a problem in dynamically typed languages or languages like Kotlin, Swift, etc. I think it's more just what you're used to.

Maybe an in-between solution could be a tool that substitutes auto in your code.

You will typically find bugs go up when you do not use auto in most average C++ code bases because, as noted by another comment, a lot of C++ developers have the bad habit of writing uninitialized variables, which auto prevents.

Type inference is actually very useful you just need to have the right amount, too little and most of your time is spent on bureaucracy, too much and the software is incomprehensible.

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)

v is double& in your example, not double. But it's not obvious that omitting the & causes a copy. If you see "for (auto v : vec)" looks good right? But if vec contains eg long strings, you've now murdered your perf because you're copying them out of the array instead of grabbing refs. Yes, you could make the same mistake without auto, but it's easier to notice. It's easy to forget (or not notice) that auto will not resolve to a reference in this case, because using a reference is "obviously what I want here", and the name of the feature is "auto" after all - "surely it will figure it out, right?"

+1 I agree 100% use it everywhere and let LS/IDE infer it.

On top of that:

* Reduce refactoring overhead (a type can be evolved or substituted, if it duck types the same, the autos don't change)

* If using auto instead of explicit types makes your code unclear, it's not clear enough code to begin with. Improve the names of methods being called or variable names being assigned to.

I can see explicit types when you are shipping a library, as part of the API your library exposes. Then you want types to be explicit and changes to be explicit.

I'd suppose this really depends on how you are developing your codebase but most code should probably be using a trailing return type or using an auto (or template) return type with a concept/requires constraint on the return type.

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.

Same in Java and Kotlin, but then again, the majority of people who write code wouldn't understand what I mean when I say "whether a collection is returned as List or Set is an important part of the API 'contract'".

The pain of lisp without any of the joy.

Rust types can be very verbose, RefCell<Optional<Rc<Vec<Node>>>>

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.

This has got to be a hell of a story if it's true.

this sounds hilarious, please do tell. Does it relate to volatility spikes when tariffs are announced and some unexpected overflow?

Romanes eunt domus

Type deduction is a form of type inference, a very restricted/crude form of type inference that only considers the type of the immediate expression. The term is used in C++ because it predates the use of auto and was the term used to determine how to implicitly instantiate templates. auto uses exactly the same rules (with 1 single exception) as template type deduction, so the name was kept for familiarity. If instead of initializing a variable, you went through the examples on this website and passed the expression into a template function, the type would be deduced in exactly the same way with the exception of initializer lists.

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...

Type inference is when you try to infer a type from its usage. ``auto`` does no such thing, it just copies a known type from source to target. Target has no influence over source's type.

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

Inference is a constraint solving problem: the type of a variable depends on all the ways it is used. In C++, deduction simply sets the type of a variable from its initializing expression.

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

[1] percentage made up on the spot.

The same general concepts often have different terminology between different languages. For example, which is better, a parent class or a super class? Or a method function or a member function? Initializer or constructor? Long list of these synonyms.

Most of the relevance of this is limited to C++ library authors doing metaprogramming.

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.