Skip to content

Instantly share code, notes, and snippets.

@erica erica/
Last active Feb 6, 2017

What would you like to do?

Disambiguating SwiftPM Naming Conflicts

  • Proposal: TBD
  • Author(s): Erica Sadun
  • Status: TBD
  • Review manager: TBD


This proposal creates a way to resolve SwiftPM module conflicts. It introduces namespacing to handle the rare case of name overlaps without requiring a central package registry.

This proposal was discussed on the Swift-Dev and Swift-Build-Dev lists in the "Right List?" thread.


Swift offers a built in mechanism for distinguishing symbol conflicts. When working with NSView, using Swift.print outputs text to the console or stream. NSView's print creates a print job. Swift does not yet offer a solution for conflicting module names.

Like many other Swift developers, I have spent considerable time building utility packages. Mine use obvious names like SwiftString and SwiftCollections because simple clear naming is a hallmark of Swift design. At the same time, this style introduces the possibility of package name conflicts.

import SwiftString // mine
import SwiftString // someone else's. oops.

Two SwiftString packages cannot be used simultaneously without some form of namespace resolution. Moving back to Cocoa-style namespacing, for example ESSwiftString, feels ugly and antithetical to Swift. Swift should encourage recognizable, easy-to-understand module names. This proposal addresses this rare but possible conflict.

Under the current system, same-named modules:

import PackageDescription
let package = Package (
    name: "myutility",
        dependencies: [
	    .Package(url: "",
	             majorVersion: 1),
	    .Package(url: "",
	             majorVersion: 1),


produce the following errors:

% swift build
Cloning Packages/SwiftString
Using version 1.0.5 of package SwiftString
Cloning Packages/SwiftString
/usr/bin/git clone --recursive --depth 10 /home/erica/Work/test/Packages/SwiftString
fatal: destination path '/home/erica/Work/test/Packages/SwiftString' already exists and is not an empty directory.

swift-build: Failed to clone to /home/erica/Work/test/Packages/SwiftString
Makefile:3: recipe for target 'all' failed
make: *** [all] Error 1

Detail Design

Under this proposal, the Swift Package manager uses reverse domain naming to differentiate otherwise identically-named items. The two conflicting packages in the following example:

import PackageDescription
let package = Package (
    name: "MyUtility",
    dependencies: [
	.Package(url: "",
                 majorVersion: 1),
	.Package(url: "",
                 majorVersion: 1),

unpack to Packages/com.github.erica.SwiftString and Packages/com.github.bob.SwiftString rather than Packages/SwiftString.

These can then be imported using the full RDN notation:

import com.github.erica.SwiftString
import com.github.bob.SwiftString

Reverse domain names

  • are rarely used outside the import statement and only to distinguish overlapping implementations
  • are relatively short
  • are already well established for Apple app distribution
  • are tied to the hosting repo

Future Directions

However concise, using reverse domain names bring verbiage to name conflicts. Upon adopting this proposal, I intend following through with language specific proposals that allow either import as or right-to-left namespacing.

A Swift import as statement would allow a developer to rename a module on import:

import com.github.erica.SwiftString as EricaString

A right-to-left alternative would require only as much of the reverse domain name prefix as needed to distinguish one implementation from another, for example:


although presumably the fully specified RDN prefix could be used as well:



Thanks to Joe Groff, Ankit Aggarwal, Max Howell, Daniel Dunbar, Kostiantyn Koval


This comment has been minimized.

Copy link

commented Feb 29, 2016

This sounds perfect!
Two things though:

  • Maybe localName could be importName or importAs
  • What happens when module names (maybe localName and name or both localName) clashes? Fail to build?

This comment has been minimized.

Copy link
Owner Author

commented Feb 29, 2016

Modified per suggestions. importAs scans better, so I chose that. Added note about clashes (should cause compilation error)


This comment has been minimized.

Copy link

commented Feb 6, 2017

Hi -- I came across this gist when encountering a module name conflict between two separate packages. Was this proposal ever implemented? Circa Feb 2017, is there a current solution to when ones needs to depend on both PackageA/moduleFoo and PackageB/moduleFoo. Sorry for posting here, was not sure where else I should try... Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.