> have an autoformatter that replaces `auto` with `std::vector<std::string>::iterator` or whatever the abomination of a type you need is :P

I don't know, that is obscuring a lot of details. I think we really need it to be

   std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::alocator<std::basic_string<char, std::char_traits<char>, std::allocator<char>>>::iterator

How would I be expected to understand the code if I didn't know what char_traits are used in the vector's allocator when opening the file in ed???

You get that in the compiler error messages when you forget a ; 10 lines above ... best of both worlds ...

> where I code without types and it's perfectly fine

Is it? In my experience it goes downhill with the square of the size of the project.

That one 500 line glue script that does one thing and interacts with just the standard library? No types, yeah baby!

That 50k line app partly written by some dude who doesn't work here any more? Now it's getting annoying.

More? Even worse.

I think you are missing the root idea here:

- you write "auto" as the type.

- You run a script that updates your code and replaces "auto" with the appropriate type for you to review and keep in the code.

But... by the time I get to run the script I've already written the code so I have no more need to know what that auto signified.

Hmm perhaps auto should be an IDE function and not a language feature? Type:

auto blih = *that_custom_collection_from_the_legacy_code_base->begin();

and when you press enter it replaces it with the proper type.

True story. I could use that right now :)

a preprocessor program is how an IDE would do that under the hood and is accessible in general too.

I worked on a ~350kloc (dry) code base for 10 years. It was perfectly fine.

I also worked on a much smaller C++ code base for 9. It was very bad.

Types or not isn't the big thing here. It's having a good engineering culture.

The team trumps anything of course, because they can work around anything if they decide to.

But my experience is with different code bases mostly done by the same people across time. And in that case you start wishing for types on the larger projects...

You mean different people surely? If it's the same people, the lack of types should be less of a problem.