I'm trying to use Károly Lőrentey's B-tree based OrderedSet in a project. However, I'm running into an issue where I can't declare an unqualified OrderedSet<T> because the name conflicts between Foundation's NSOrderedSet (imported as OrderedSet in Swift 3) and BTree's OrderedSet.
let set = OrderedSet<Int>() // error: 'OrderedSet' is ambiguous for type lookup in this context // Found this candidate: Foundation.OrderedSet:3:14 // Found this candidate: BTree.OrderedSet:12:15 To resolve this conflict, you would normally qualify the name, and that would give you BTree.OrderedSet<T>. However, the BTree module also contains a class named BTree. If I write BTree.OrderedSet, Swift thinks that I'm referring to a type named OrderedSet that is nested in the BTree.BTree type.
let set = BTree.OrderedSet<Int>() // error: reference to generic type 'BTree' requires arguments in <...> If I don't import BTree, I can't use the BTree name at all.
// no import BTree let set = BTree.OrderedSet<Int>() // error: use of undeclared type 'BTree' How can I resolve this ambiguity between the BTree type and the BTree module?
The type can be disambiguated using the little-known import (class|struct|func|protocol|enum) Module.Symbol syntax.
import struct BTree.OrderedSet From this point on, OrderedSet unambiguously refers to the one in BTree.
If this would still be ambiguous or sub-optimal in some files, you can create a Swift file to rename imports using typealiases:
// a.swift import struct BTree.OrderedSet typealias BTreeOrderedSet<T> = BTree.OrderedSet<T>
// b.swift let foo = OrderedSet<Int>() // from Foundation let bar = BTreeOrderedSet<Int>() // from BTree There was a new syntax discussed for Swift 3, but it fell through.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With