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

[Tommaso Piazza]

Hi,
I just wanted to revive this discussion and understand if this is a welcome change or not.
Right now one can "fake" overload 1 inside NonEmptyArray by doing the following:
```
public struct NonEmptyArray<Element> {
    private var elements: Array<Element>
    private init(array: [Element]) {        self.elements = array    }
        public static func cons<Element>(lhs: Element, rhs: [Element]) -> NonEmptyArray<Element> {        return NonEmptyArray<Element>(array: rhs + [lhs])    }```
And "fake" the operator by calling the cons function
```//Overload 1public func •|<Element>(lhs: Element, rhs: [Element]) -> NonEmptyArray<Element> {    return NonEmptyArray.cons(array: rhs + [lhs])}```
While this is ok and gets the job done, it seems and artificial limitation (and a bit inconsistent) that only overloads mentioning the struct/class type in the operands are allowed.

I have updated my proposal to reflect this argument as well blender/swift-evolution
  
|  
|   
|   
|   |    |

   |

  |
|  
|    |  
blender/swift-evolution
 swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming La...  |   |

  |

  |

 



 

    On Sunday, December 11, 2016 11:33 AM, Tommaso Piazza via swift-evolution <swift-evolution at swift.org> wrote:
 

 Hello Derrick,
I did not think of this as a bug but rather as an intentional limitation that to me seems a little odd.
Yes, overloads 2,3 have at least ONE operand of type NonEmptyArray so when declared as static function on NonEmptyArray they work fine. However Overload 1 just mentions NonEmptyArray in the return type. I propose that it should also be allowed as a static function on NonEmptyArray.
As for the why it should be allowed my motivation is that all overloads that mention NonEmptyArray in their type signature should be allowed to be declared in the same namespace.Or one could argue that no overloads should be declarable inside NonEmptyArray. 
However this comes at a price.
Note that because overload 1 in the current situation must be left out of NonEmptyArray, the accessor modifier for properties and function in NonEmptyArray is fileprivate.With the change I propose this is no longer the case and the modifier is just private.
/Tommaso
    On Sunday, December 11, 2016 5:49 AM, 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



   
_______________________________________________
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/20161213/407fda70/attachment.html>