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
<[email protected]> 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 <[email protected]>
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
<[email protected]> wrote:
On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution
<[email protected]> wrote:
On Dec 10, 2016, at 4:54 PM, 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
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
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
