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

[Tommaso Piazza]

Thanks for the suggestion,
I have updated the proposal with the error and with the notes on `fileprivate` -> `private`
/Tommaso 

    On Sunday, December 11, 2016 5:55 AM, Derrick Ho <wh1pch81n at gmail.com> wrote:
 

 You may want to add the specific error to your proposal.  
error: member operator '•|' must have at least one argument of type 'NonEmptyArray<Element>'        public static func •|<Element>(lhs: Element, rhs: [Element]) -> NonEmptyArray<Element>
On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho <wh1pch81n at gmail.com> wrote:

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/567ccd15/attachment.html>