CODEWITHSUNDEEP
iosswiftcocoapods
Tahdiul Haq
Tahdiul Haq

Reputation: 255

Namespace Conflict in swift with cocoa pod module

I have an enum in one of my Swift files called Foo. One of the Cocoapods called NameA also has the same enum with name Foo (public enum, not inside any class). This module also has a class with the same name as its framework NameA.

If I try to refer to Foo in NameA module like this:

NameA.Foo

It doesn't work because the compiler thinks I'm referring to the class NameA, but not the module NameA. The workaround posted here wont work for me either Swift namespace conflict

This seems to be a reported bug in swift: https://bugs.swift.org/browse/SR-898

Upvotes: 6

Views: 3213

Answers (3)

iKushal
iKushal

Reputation: 2869

If you want to use enum from other module like Cocoapods or some framework you have to use this approach,

suppose I have enum Result defined in my project and same in some other module. You want to use both enum in same file then-

import enum MyFramework.Result

func doSomething(callback: (Result<Data>) -> Void) {

}

func doSomething1(callback: (MyFramework.Result<Data>) -> Void) {

}

Upvotes: 0

Gazzini
Gazzini

Reputation: 738

  • Don't import NameA.

  • Instead, import enum NameA.Foo (notice the keyword "enum", can also be used for "struct" or "class" or "func")

  • Reference either Foo (your enum) or NameA.Foo (their enum).

If you need to reference NameA in the same file as NameA.Foo:

  • Create a new file for your "wrapper" type:

import NameA typealias NameAWrapper = NameA

  • Reference the class NameA as NameAWrapper in your other files without importing the module directly.

This was inspired by this workaround (which you linked to), but modified slightly based on your situation: https://stackoverflow.com/a/26774102/358806

Upvotes: 11

Mike Cole
Mike Cole

Reputation: 1301

I ran into a similar issue recently. You won't like the solution I found, but I'll share it anyway. I had to fork the pod I was using and rename it to something new. The new project name no longer conflicted with the class name and I was able to namespace it as MyForkedName.ClassName. This is really an inconvenient way to do it, but in our case it was an older library that hadn't changed in some time (and one we will be removing altogether in the future) so I was willing to settle for now.

Upvotes: 0

Related Questions