[swift-evolution] Module conflicts (was: Overridable Members in Extensions)

Max Howell max.howell at apple.com
Fri Feb 19 11:51:39 CST 2016

> But when modules themselves conflict, we're in trouble. Module name uniqueness is a pretty strong part of guaranteeing the uniqueness of everything else. You can't just rename them if there's a conflict, because they show up in, say, NSCoding archives. We've mostly just pushed the ObjC prefix problem up a level.
> Max from the Package Manager team may have more thoughts here; over on swift-build-dev this is a very practical problem.

There is no conversation on this topic yet. For me there’s a few solutions:

* Namespacing that the PM can enforce but can be transparent (mostly) to users. Specifically, I compile modules with an additional namespace in front (for example, with a github project this could be the username) (this would presumably be a flag to the compiler). Then in general use this is hidden, you import modules the same. It’s only when both modules are to be imported the user has to be specific. This option obviously would require buy-in from Swift-core as well as lots of evolution discussion.
* SwiftPM mangles module names transparently. This would require a pre-processor step that transforms all sources into a second form with the mangled import names.

2) is obviously gross, but the option exists.

If you want us to get started discussing this then by all means copy this to a new evolution thread. But otherwise I’ll start the conversation in a few weeks.

The problem with 1) is it may not be doable in a Swift 3 timeframe, but bringing the conversation up will at least confirm or deny that.

More information about the swift-evolution mailing list