importing Focus and Swiftz cause operators such as ||| to fail to compile

[BrianDoig]

import Swiftz 
import Focus

func fanin<A, B, C>(_ l: @escaping (A) -> C, _ r: @escaping (B) -> C) -> Function<Either<A, B>, C> {
    return Function.arr(l) ||| Function.arr(r)
}

The above fails to compile and there doesn't seem to be a way to specify which library you want the operator to come from since Swiftz.||| fails to compile.

***: error: ambiguous operator declarations found for operator
return Function.arr(l) ||| Function.arr(r)
^
:0: note: found this matching operator declaration
:0: note: found this matching operator declaration
***: error: operator is not a known binary operator
return Function.arr(l) ||| Function.arr(r)

[CodaFi]

You're using git submodules or Carthage, no? SwiftPM should be able to resolve the dependency properly - or not, I remember it had some problems with top-of-tree dependencies. But it's nothing we can't fix by editing the package file.

[CodaFi]

If git submodules are a requirement, the correct answer is to write two different Swift files for code that needs Focus and code that needs Swiftz and use wrapper functions to bridge the gaps where necessary. A terrible problem to have, but one introduced by a source-breaking change in the proposal that "simplified operator declarations".

[BrianDoig]

Unfortunately, it's either git submodules or CocoaPods that I have to use. Since CocoaPods doesn't work at the moment, I'm stuck with submodules. I ended up doing what you suggested. My above example was actually one of my wrapper functions to get around it.

It's not like it's uncommon for multiple libraries to declare their own operators and for there to be no way to resolve conflicts seems like a serious design flaw on the part of the Swift team.

[BrianDoig]

Ended up getting approval to use Swift package manager so that took care of the problem.