Proposal: Allows operator overloads in struct or classes based on return type


(Tommaso Piazza) #1

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


(David Sweeris) #2

That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not aware of the reasoning.

- Dave Sweeris

···

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <swift-evolution@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


(David Sweeris) #3

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

···

On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.


(Robert Widmann) #4

I remember mentioning this in a meeting once. The old behavior (post 2.x-mid-operators-in-aggregates) did allow for this, the new one should too.

~Robert Widmann

2016/12/10 20:36、David Sweeris via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Derrick Ho) #5

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

On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #6

imho the current behaviour is fine.

I'll leave aside infix-operators, because with pre/postfix, the situation is simpler:
It seems slightly confusing to me to declare such an operator somewhere else but at the type it works on.

Afair the ability to declare an infix operator in a type definition came with the redefinition of access levels, possibly motivated by the ability to use private properties.
This might as well be the reason not to enforce that the operator has to be defined in the type of the first operand (which I'd consider to be preferable whenever possible).


(Tommaso Piazza) #7

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&#39;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&#39;s really up to you\.
/Tommaso

<details class='elided'>
<summary title='Show trimmed content'>&#183;&#183;&#183;</summary>

On Sunday, December 11, 2016 1:57 AM, Tommaso Piazza via swift\-evolution &lt;swift\-evolution@swift\.org&gt; 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@swift\.org
https://lists.swift.org/mailman/listinfo/swift-evolution

</details>

(Derrick Ho) #8

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

On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tommaso Piazza) #9

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

On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tommaso Piazza) #10

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

On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tommaso Piazza) #11

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
&nbsp;&nbsp;
> &nbsp;&nbsp;&gt;    &gt;

&nbsp;&nbsp;&nbsp;&gt;

&nbsp;&nbsp;&gt;
> 
> &nbsp;&nbsp;&nbsp;&gt;  

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

&nbsp;&nbsp;&gt;

&nbsp;&nbsp;&gt;

 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

<details class='elided'>
<summary title='Show trimmed content'>&#183;&#183;&#183;</summary>

On Sunday, December 11, 2016 11:33 AM, Tommaso Piazza via swift\-evolution &lt;swift\-evolution@swift\.org&gt; wrote:
&nbsp;&nbsp;&nbsp;&nbsp;On Sunday, December 11, 2016 5:49 AM, Derrick Ho &lt;wh1pch81n@gmail\.com&gt; 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&lt;Element&gt; \{

&nbsp;&nbsp;&nbsp;&nbsp;fileprivate var elements: Array&lt;Element&gt;

&nbsp;&nbsp;&nbsp;&nbsp;fileprivate init\(array: \[Element\]\) \{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;self\.elements = array
&nbsp;&nbsp;&nbsp;&nbsp;\}
\}

//Overload 1
public func •|&lt;Element&gt;\(lhs: Element, rhs: \[Element\]\) \-&gt; NonEmptyArray&lt;Element&gt; \{
&nbsp;&nbsp;&nbsp;&nbsp;return NonEmptyArray\(array: rhs \+ \[lhs\]\)
\}

//Overload 2
public func •|&lt;Element&gt;\(lhs: Element, rhs:  NonEmptyArray&lt;Element&gt;\) \-&gt; NonEmptyArray&lt;Element&gt; \{
&nbsp;&nbsp;&nbsp;&nbsp;return NonEmptyArray\(array: \[lhs\] \+ rhs\.elements\)
\}

//Overload 3
public func •|&lt;Element&gt;\(lhs: NonEmptyArray&lt;Element&gt;, rhs: NonEmptyArray&lt;Element&gt;\) \-&gt; NonEmptyArray&lt;Element&gt; \{
&nbsp;&nbsp;&nbsp;&nbsp;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&lt;Element&gt;\. 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 &lt;swift\-evolution@swift\.org&gt; wrote:

On Dec 10, 2016, at 5:29 PM, David Sweeris via swift\-evolution &lt;swift\-evolution@swift\.org&gt; wrote:

On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift\-evolution &lt;swift\-evolution@swift\.org&gt; 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@swift\.org
https://lists.swift.org/mailman/listinfo/swift-evolution

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
swift\-evolution mailing list
swift\-evolution@swift\.org
https://lists.swift.org/mailman/listinfo/swift-evolution

</details>

(Douglas Gregor) #12

This was intentional:

  https://github.com/apple/swift/commit/a15c485193c4dcb61c330be8c2d869758fff2c45

We believe that this restriction will help us provide more fine-grained dependency tracking in the compiler, which is important for minimizing the work to be performed in incremental builds. The general idea is that one can only find a particular operator when one has an argument of the type in which the operator is defined (or one of its subclasses or conforming types). I believe that we lose this fine-grained dependency if we allow the enclosing type to be mentioned (only) in the result type. So unless I’m wrong about one of those two things—either we don’t actually get the fine-grained dependency I’m expecting or we can still get it even if the enclosing type is only mentioned in the result type—I’m strongly against lifting this restriction. Incremental build times and fine-grained dependencies are extremely important for Swift compile times, and the language already has a way out by defining a global operator.

  - Doug

···

On Dec 11, 2016, at 2:30 AM, Tommaso Piazza via swift-evolution <swift-evolution@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.