[dataflow]

It's less problematic in that case, but still problematic. It's less apparent during initial authorship, because you often have all the names that might collide already in your head at that point. It's during later maintenance when you lack context (like when you/your coworkers haven't seen, or don't recall, the code) that the problems become more apparent. You're basically digging holes behind you as you're walking along, and even though you might not trip over them, someone else walking on that path eventually will.

[CyberDildonics]

Not really. If someone is using vector<type> or unordered_map it's unlikely its anything else and if you are using an IDE, you can check easily. You are basically implying that anything short of full names are a problem which is just not true.

[dataflow]

> Not really. If someone is using vector<type> or unordered_map it's unlikely its anything else

There are far less distinctive names than those in namespace std. Have you seen remove(), erase(), move(), search(), apply(), hash, format(), etc.?

Not to mention std::operator overloads like == and < that you suddenly drag into overload resolution needlessly, which can bring their own fun into the mix.

> if you are using an IDE, you can check easily

Lots of people don't. And even those who do, don't immediately have the symbol available to go to its definition. It's quite normal to have to wait O(minutes) for semantic analysis to become ready.

> You are basically implying that anything short of full names are a problem which is just not true.

No, very much not so. If you use it on something that's unlikely to collide (like std::cerr), `using std::foo;` is generally fine outside of headers. `using namespace std;` is the one that's problematic.

[CyberDildonics]

Lots of people don't.

If they did they wouldn't have these problems of wondering where functions are defined.

Who are these people not using an IDE when working professionally with a team of people? That's a much bigger red flag than putting using namespace std; inside a compilation unit.

If there is ambiguity, then you can just add a std:: in front of a function. This is all within a single compilation unit anyway.

[dataflow]

> Who are these people not using an IDE when working professionally with a team of people? That's a much bigger red flag than putting using namespace std; inside a compilation unit.

You seem to have completely ignored what I wrote after "even those who do..."? Like I explained, you're not immune to these issues just because you use an IDE.

And to answer your question, it's lots of people at companies whose C++ talent you would (or should) appreciate. And many people use both IDEs and text editors, depending on lots of factors, like the size of the task.

> If there is ambiguity, then you can just add a std:: in front of a function. This is all within a single compilation unit anyway.

Just because it's in a single TU that doesn't mean it won't be somebody else's problem.

First, someone who modifies a header you include will now potentially break your code simply via a name collision. You're making it harder for them to change their code without breaking yours. And you're probably not their only consumer.

Second, you're now doing ADL lookups instead of regular lookups. This can add a ridiculous amount of noise to error messages for widely used identifiers, which will make life much harder for everyone.

Third, not everything results in an ambiguity. The moment someone introduces an overload that happens to be a better match for your lookup, this can silently cause your code to misbehave. It might not be the most common problem but it's sure as heck one of the most painful when you or your teammates eventually get bitten.

[CyberDildonics]

First, someone who modifies a header you include will now potentially break your code simply via a name collision.

That would mean that they are writing their own global functions that collide with the standard library which is a pretty big mistake itself.

Part of knowing the standard library is knowing not to make some function called end() in the global namespace. This really isn't a big deal. It's one of those group think ideas that permeates and lots of these jihads in programming have been totally wrong. This one I think is just blown out of proportion. There is a lot of simplicity in not having huge long lines for every type. Part of this can be done with auto, part of it can be done with aliasing, but an isolated namespace declaration isn't the end of the world.

[dataflow]

> Part of knowing the standard library is knowing not to make some function called end() in the global namespace.

For end(), sure. But I listed a bunch more names that are way more likely to collide though... remove(), erase(), move(), search(), apply(), hash, format() are way more likely to collide. The fact that you have to pick the most implausible names to make your argument should be enough evidence that it's a strawman.

> That would mean that they are writing their own global functions that collide with the standard library which is a pretty big mistake itself.

No. It just means you're in the same namespace, or a sub-namespace of theirs.

You're also ignoring ADL effects and silent overload resolution changes, which I mentioned already.

> It's one of those group think ideas that permeates and lots of these jihads in programming have been totally wrong.

You've made factual mistakes in a bunch of your arguments -- most recently your misconception that such collisions only happen with the global namespace. Calling this "group think" and "totally wrong" when your arguments rest on incorrect assumptions is not really warranted.

> There is a lot of simplicity in not having huge long lines for every type.

You're arguing as if we don't understand that... despite the fact that I evidently did, as I explained earlier how you could achieve that simplicity by doing "using std::foo;" instead of "using namespace std;", while avoiding the vast majority of the downsides I'm pointing out.

OTOH, what you don't seem to be considering (and which I've been trying to point out) is the various types of friction you're introducing for your coworkers and future maintainers.

> an isolated namespace declaration isn't the end of the world.

"Not end of the world" is a... low bar. Just because a practice isn't the end of the world, that doesn't mean avoiding it isn't a better idea. I've pointed out several reasons why: unintended ADL lookups, ridiculous error message noise, silent misbehavior, name collisions, difficulty of changing dependent code without breakages, etc. And I've pointed out how you can still achieve your goal while mitigating these considerably.

I don't have anything else to add.