[swift-build-dev] [swift-dev] Right list?

[Max Howell]

> Can you explain a little more about your motivation for this?
> 
> I understand that "SwiftString", as a package, may be something which is likely to conflict. It isn't however clear to me that most packages fall into that category, or that it is even desirable to support features that encourage it.

I don’t mean to intercept Erica here, but I wanted to chime-in.

For me, my motivation is we don’t have a single index, so it is quite likely that module names will collide at some point.

We need some solution for this. Originally I was thinking, well lets allow overrides for module-names, which is still an option, but it is not as simple as I originally hoped since any packages that depend on that module in a deep tree will require either:

1) Swift-the-language support for the rename.
2) Or a preprocessor step in the Package Manager that renames module imports in affected packages.

Namespaces are more elegant, especially if by default you don’t have to care. Packages would only have to care if they import two modules with the same name, and this would be discovered by the package author, not by the end-user who just happened to depend on the wrong combination of packages.

Also, personally, I want people to call their packages “StringExtensions”. Currently the iOS development world is filled with silly names for packages, and this partly happens because the good names are already taken. People would instead say “Daniel Dunbar’s String Extensions” and for me, that is what the package should be called.

> For packages like "libjpeg", "LLVM", "OpenGL", "ncurses", "zlib", it seems like having one global namespace is OK, and even useful. As a Python user, for example, I have never been bother that the Python package index is a global namespace.

Yes, this is separate (for me). And handled by module map packages.