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

[Derrick Ho]

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/82e60d54/attachment.html>