I placed he code you wrote in the proposal in playgrounds and it works perfectly. (reproduced below). Overloading operators used to only happen globally and since swift 3 they allowed you to put then inside the class/struct
public struct NonEmptyArray<Element> { fileprivate var elements: Array<Element> fileprivate init(array: [Element]) { self.elements = array } } //Overload 1 public func •|<Element>(lhs: Element, rhs: [Element]) -> NonEmptyArray<Element> { return NonEmptyArray(array: rhs + [lhs]) } //Overload 2 public func •|<Element>(lhs: Element, rhs: NonEmptyArray<Element>) -> NonEmptyArray<Element> { return NonEmptyArray(array: [lhs] + rhs.elements) } //Overload 3 public func •|<Element>(lhs: NonEmptyArray<Element>, rhs: NonEmptyArray<Element>) -> NonEmptyArray<Element> { return NonEmptyArray(array: lhs.elements + rhs.elements) } However, as you have detailed when you place those overloads inside the struct/class, it does not work. Actually I get an error that says that at least ONE of the arguments needs to be the same type. In this case one of them needs to be NonEmptyArray<Element>. It is clearly not a bug, but rather a swift rule. My recommendation is to just keep those overloads as global. Is there a particular advantage to putting them inside the struct/class? On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello, > > I have written a small proposal that would allow overloads of operators in > structs/classes non only based on the types of the operands but on the > return type as well. > > Please let me know you thoughts, > /Tommaso > > > https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/NNNN-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md > > > That seems like a bug to me… Dunno, maybe it’s intentional and I’m just > not aware of the reasoning. > > > Actually, since the error message correctly parses the code, it probably > *is* intentional… I don’t see the problem, myself, but I guess I’d have > to know why it’s considered an error before judging whether I think we > should remove the restriction. > > - Dave Sweeris > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution