Needs design. import … as … is one possible answer.

Comment by Evan Maloney (JIRA)

I've hit this issue as well, and have discovered that it doesn't require the use of generics to trigger it.

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
    }
}

After circulating the problem above to the Swift-Users mailing list, @belkadan reached out with a (correct) hunch that the underlying problem was that I have a type that has the same name as the module.

In fact, the AppleTart module contained a type also named AppleTart, which acts as an interface for controlling the framework that vends the module. I renamed the type to AppleTartFramework and am no longer experiencing the problem.

Comment by Vladimir Shabanov (JIRA)

Please fix. There are problems with importing custom obj-c error classes (descendants of NSError) even from single custom Obj-C framework to Swift app.

Also see SR-14142 where this missing language feature is causing emitted swiftinterface files to fail to compile.