[swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

Derrick Ho wh1pch81n at gmail.com
Sat Dec 10 22:49:21 CST 2016


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 at swift.org> wrote:

> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161211/cd2eb4c8/attachment.html>


More information about the swift-evolution mailing list