I recently ran into a situation where I needed to import a symbol with the same name from two different modules, and noticed that the usual Swift technique of disambiguating using the package name doesn't work when used with extensions.
In my case, I have a package 'LegacyStore' and a package 'AppleTart', both of which contain a type named 'User'.
In the case of LegacyStore, User is an Objective-C class, and in the case of AppleTart, User is a Swift struct.
Normally, I'd be able to refer to one as 'LegacyStore.User' and the other as 'AppleTart.User', but when using this notation for an extension:
extension AppleTart.User
{
public var legacyUser: LegacyStore.User {
// implementation
}
}
...I get a compiler error on the extension declaration line:
error: 'User' is not a member type of 'AppleTart'
Note that the 'LegacyStore.User' notation used in the var declaration never triggers a compiler error, so I'm assuming the notation just isn't supported yet in the context of declaring an extension.
Fortunately, there's a (somewhat cumbersome) work-around, which is to create two separate files, one for each module. Within each file import just that one module, and create a typealias for each clashing name using package-qualified name of the type.
For example, here's the relevant part of my AppleTartTypeDisambiguation.swift file:
import AppleTart
public typealias AppleTartUser = User
And here's my LegacyStoreTypeDisambiguation.swift file:
import LegacyStore
public typealias LegacyUser = User
I can then use the typealiases to extend either type. For example, here's how I successfully extended AppleTart.User:
extension AppleTartUser
{
public var legacyUser: LegacyStore.User {
// implementation
}
}
Should the inability to extend a type using the qualified type name be considered a compiler bug? I'm assuming yes. If so, I'll file a ticket.