[xyrouter]

> this kind of system that relies on the whole codebase having no localized type annotations (so you can’t reason locally about code when you go to refactor or change types, etc.), is so egregiously bad.

Nobody said that either. The parent comment specifically said that they have alternate types to provide different performance characteristics and behavior. Such code bases do exist contrary to what you believe.

Don't think of it as an Apple type suddenly replaced with an Orange type on one fine day and your head begins to spin when you try to understand what the code does.

Think of it more like int32_t being replaced with int_fast32_t because you realize you want to port the code to a new architecture due to which int_fast32_t makes more sense now. Now the argument should not appear as "egregiously bad" as you make it look like.

The world of software development is far more heterogeneous than what your experience might have led you to believe.

[jcelerier]

My particular cases are with various implementations of hash maps and ordered maps that I switch, for instance std::{unordered_,}map, boost::flat_map, pubby::flat_map, tsl::hopscotch_map, ska::flat_hash_map, and a few others.

[mlthoughts2018]

It’s funny to hear someone say it is “very rigid beliefs” to disagree with dogmatically using auto everywhere just to get polymorphism by swapping header files, which is a far more drastic and brittle belief.

I have worked on systems deploying to embedded devices, so I am familiar with e.g. needing to suddenly change a bunch of code to cause some typedef to refer to int16 because a platform doesn’t support int32, and needing the codebase to be robust to the change. Whatever solution you pick, sacrificing localized explicit type info is not a good trade-off, and ability to read code and locally easily reason about types only gets more critical as the application gets more architecture or performance dependent.

Besides, many systems that need to achieve this same effect do so by either using discriminated union (std::variant) and multiple dispatch patterns, or by designing the different specific subtypes to fit into an inheritance hierarchy, so that switching things to use e.g. different integer precisions is a matter of using a different, specialized subtype. Forcing the use of auto everywhere and switching types by header files would be a nuclear option by comparison.

[xyrouter]

> ability to read code and locally easily reason about types only gets more critical as the application gets more architecture or performance dependent

Exactly! And using auto for variables with very limited scope where the type is obvious effortlessly does not negatively affect the ability to read code and in my opinion improves the ability to read code.