[am17an]

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.

I remember fretting about these rules when reading Scott Meyer's Effective C++11, and then later to realize it's better not to use auto at all. Explicit types are good types

[guenthert]

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

Looking up the (current standard's) return type of std::chrono::steady_clock::now() and spelling it out would serve no purpose here.

[cjfd]

With 'auto' it is so very verbose. It can be shorter. Let us put "using TP = std::chrono::steady_clock::time_point;" in some header file to be used in many places. Now you can write

  TP start = TP::clock::now();
  do_some_work(size);
  TP end = TP::clock::now();

[am17an]

I agree, this would be in the same vein as "STL returns a verbose type, it's okay to use auto here because no-one cares"

[moregrist]

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

[nly]

Implicit type conversions blow your reasoning out of the water imho

The number of times someone has assigned a return type to int, triggering an implicit conversion.

I'll take "unintelligible compile errors" any day over subtle runtime bugs.

[112233]

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"?

[dosshell]

If it captures variables, it is not possible to manually declare the type. You can however hide it in an std::function. But then you probably get some overhead and some heap allocations in real life.

[maxlybbert]

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.

[Moldoteck]

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

[cjfd]

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.

[spot5010]

Pre LLM agents, a trick that I used was to type in

auto var = FunctionCall(...);

Then, in the IDE, hover over auto to show what the actual type is, and then replace auto with that type. Useful when the type is complicated, or is in some nested namespace.

[nly]

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

[spacechild1]

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

Really? I've never experienced this myself.