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 <wh1pch...@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 <wh1pch...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
