I cannot reply directly to this message
https://www.mail-archive.com/[email protected]/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
<[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
