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

[Tommaso Piazza]

I cannot reply directly to this message https://www.mail-archive.com/swift-evolution@swift.org/msg19099.html so I will reply here instead.
I am suggesting that both behaviours should be allowed to co-exists (which is already the case, just there is this one exception.)
No matter the implications of access level I see this as a matter of consistency as well, at the end of the day an operator is a function with some sugar and a special name.
So while I am able to declare a static function as part of a struct/class like so:
```
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])}```
It seems to me that the only reason we're currently not allowed to declare the operator directly inside NonEmptyArray is because is begins with some special UTF8 character.
If you want to define your overload as free form functions or as static methods on structs/classes it's really up to you.
/Tommaso 

    On Sunday, December 11, 2016 1:57 AM, 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



_______________________________________________
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/1732e087/attachment.html>