[Pitch] Deeper Xcode Integration for SwiftPM

Development Package Manager
41

I don’t see any other motivation for why would you want to force a developer to use the submodule name. If there are no conflicts, why force them to use it?

In my particular case I have something like this where i communicate to the developer that there are references involved:

Reference.Buffer

Reference.String

Reference.Character

And so on. String or Character would collide with Swift.String and Swift.Character here. Namespaces would solve this (or submodules).

I don't support any mechanism that allows you to *require* the developer to use your (sub)module or namespace name as a prefix in all cases. However, I *do* support allowing them to *choose* to use it for either stylistic reasons or to resolve ambiguity.

···

On May 20, 2016, at 2:30 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 21:18:46, Tyler Cloutier (cloutiertyler@aol.com <mailto:cloutiertyler@aol.com>) schrieb:

I don’t see any other motivation for why would you want to force a developer to use the submodule name. If there are no conflicts, why force them to use it?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

42

I don't support any mechanism that allows you to *require* the developer to use your (sub)module or namespace name as a prefix in all cases. However, I *do* support allowing them to *choose* to use it for either stylistic reasons or to resolve ambiguity.
I’m absolutely fine with your second point, just because I’ll get my desired `Reference.Type` without abusing enums.

···

--
Adrian Zubarev
Sent with Airmail