Linking another similar discussion for context: Enable module names to be type aliased - #16 by jayton
Pulling a few notes from the link:
- Nobody wants to go back to the era of objective-c prefixes on everything. We're trying to kill NSThis and AFThat!!!
- There are edge cases where the current system is unworkable without renaming your type when a library adds a new type that conflicts with yours (due to Swift limitations not because the problem is fundamentally unsolvable). So even "do things at the module level and don't nest types" is not a workable/universal solution.
On nested types: I often reach for nested types when I want to communicate hierarchy and not end up with a bunch of top-level types. Let's say I have some Frob that has a Cache data structure that does need to be publicly visible for some reason. I don't want consumers using Frob and FrobCache types. I want consumers using Frob and Frob.Cache. Maybe it's personal preference but, not least because namespacing limitations have driven the community to de-facto adopt empty enums as a janky namespacing technique, I use the pattern pretty commonly.