<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">Hello Derrick,</div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">I did not think of this as a bug but rather as an intentional limitation that to me seems a little odd.</div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">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.</div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">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.</div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">Or one could argue that no overloads should be declarable inside NonEmptyArray. </div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">However this comes at a price.</div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">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.</div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr">With the change I propose this is no longer the case and the modifier is just private.</div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1481450784930_3708"><br></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1481450784930_3708">/Tommaso</div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1481450784930_3708"><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1481450784930_3705" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1481450784930_3704"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1481450784930_3703"> <div dir="ltr" id="yui_3_16_0_ym19_1_1481450784930_3707"><font size="2" face="Arial" id="yui_3_16_0_ym19_1_1481450784930_3706"> On Sunday, December 11, 2016 5:49 AM, Derrick Ho <wh1pch81n@gmail.com> wrote:<br></font></div> <br><br> <div class="y_msg_container" id="yui_3_16_0_ym19_1_1481450784930_3702"><div id="yiv0673440985"><div id="yui_3_16_0_ym19_1_1481450784930_3701"><div dir="ltr" id="yui_3_16_0_ym19_1_1481450784930_3700">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<div id="yui_3_16_0_ym19_1_1481450784930_3846"><br clear="none"></div><div id="yui_3_16_0_ym19_1_1481450784930_3710"><pre style="font-family:consolas, 'liberation mono', menlo, courier, monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:16px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);color:rgb(51,51,51);" id="yui_3_16_0_ym19_1_1481450784930_3709"><code style="font-family:consolas, 'liberation mono', menlo, courier, monospace;padding:0px;margin:0px;background-color:transparent;border:0px;display:inline;overflow:visible;line-height:inherit;word-wrap:normal;" id="yui_3_16_0_ym19_1_1481450784930_3711">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)
}</code></pre></div><div><br clear="none"></div><div id="yui_3_16_0_ym19_1_1481450784930_4093">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.</div><div id="yui_3_16_0_ym19_1_1481450784930_3731"><br clear="none"></div><div id="yui_3_16_0_ym19_1_1481450784930_3713">My recommendation is to just keep those overloads as global. Is there a particular advantage to putting them inside the struct/class?<br clear="none"><div id="yui_3_16_0_ym19_1_1481450784930_3725"><br clear="none"></div><div id="yui_3_16_0_ym19_1_1481450784930_3712"><br clear="none"></div></div></div><br clear="none"><div class="yiv0673440985gmail_quote" id="yui_3_16_0_ym19_1_1481450784930_3724"><div dir="ltr" id="yui_3_16_0_ym19_1_1481450784930_3726">On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution <<a rel="nofollow" shape="rect" ymailto="mailto:swift-evolution@swift.org" target="_blank" href="mailto:swift-evolution@swift.org" id="yui_3_16_0_ym19_1_1481450784930_3730">swift-evolution@swift.org</a>> wrote:<br clear="none"></div><blockquote class="yiv0673440985gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;" id="yui_3_16_0_ym19_1_1481450784930_3723"><div class="yiv0673440985gmail_msg" style="word-wrap:break-word;" id="yui_3_16_0_ym19_1_1481450784930_3722"><div class="yiv0673440985gmail_msg" id="yui_3_16_0_ym19_1_1481450784930_3721"><blockquote class="yiv0673440985gmail_msg" type="cite" id="yui_3_16_0_ym19_1_1481450784930_3720"><div class="yiv0673440985gmail_msg" id="yui_3_16_0_ym19_1_1481450784930_3729">On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <<a rel="nofollow" shape="rect" class="yiv0673440985gmail_msg" ymailto="mailto:swift-evolution@swift.org" target="_blank" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</div><br clear="none" class="yiv0673440985m_-1969521834013891672Apple-interchange-newline yiv0673440985gmail_msg"><div class="yiv0673440985gmail_msg" id="yui_3_16_0_ym19_1_1481450784930_3719"><div class="yiv0673440985gmail_msg" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;" id="yui_3_16_0_ym19_1_1481450784930_3718"><blockquote class="yiv0673440985gmail_msg" type="cite" id="yui_3_16_0_ym19_1_1481450784930_3717"><div class="yiv0673440985gmail_msg" id="yui_3_16_0_ym19_1_1481450784930_3728"><br clear="none" class="yiv0673440985m_-1969521834013891672Apple-interchange-newline yiv0673440985gmail_msg">On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <<a rel="nofollow" shape="rect" class="yiv0673440985gmail_msg" ymailto="mailto:swift-evolution@swift.org" target="_blank" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</div><br clear="none" class="yiv0673440985m_-1969521834013891672Apple-interchange-newline yiv0673440985gmail_msg"><div class="yiv0673440985gmail_msg" id="yui_3_16_0_ym19_1_1481450784930_3716"><div class="yiv0673440985gmail_msg" id="yui_3_16_0_ym19_1_1481450784930_3715"><div class="yiv0673440985gmail_msg" style="background-color:rgb(255,255,255);font-family:HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif;font-size:16px;" id="yui_3_16_0_ym19_1_1481450784930_3714"><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640">Hello,</div><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640"><br clear="none" class="yiv0673440985gmail_msg"></div><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640">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.</div><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640"><br clear="none" class="yiv0673440985gmail_msg"></div><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640">Please let me know you thoughts,</div><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640">/Tommaso</div><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640"><br clear="none" class="yiv0673440985gmail_msg"></div><div class="yiv0673440985gmail_msg" dir="ltr" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3640"><a rel="nofollow" shape="rect" class="yiv0673440985gmail_msg" id="yiv0673440985m_-1969521834013891672yui_3_16_0_ym19_1_1481417388759_3639" target="_blank" href="https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/NNNN-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md">https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/NNNN-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md</a><br clear="none" class="yiv0673440985gmail_msg"></div></div></div></div></blockquote><br clear="none" class="yiv0673440985gmail_msg"></div><div class="yiv0673440985gmail_msg" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;">That seems like a bug to me… Dunno, maybe it’s intentional and I’m just not aware of the reasoning.</div></div></blockquote><div class="yiv0673440985gmail_msg"><br clear="none" class="yiv0673440985gmail_msg"></div></div></div><div class="yiv0673440985gmail_msg" style="word-wrap:break-word;" id="yui_3_16_0_ym19_1_1481450784930_4561"><div class="yiv0673440985gmail_msg" id="yui_3_16_0_ym19_1_1481450784930_4560">Actually, since the error message correctly parses the code, it probably <i class="yiv0673440985gmail_msg">is</i> 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.</div><div class="yiv0673440985gmail_msg"><br clear="none" class="yiv0673440985gmail_msg"></div>- Dave Sweeris</div>_______________________________________________<br clear="none" class="yiv0673440985gmail_msg">
swift-evolution mailing list<div class="yiv0673440985yqt5691517778" id="yiv0673440985yqtfd24510"><br clear="none" class="yiv0673440985gmail_msg">
<a rel="nofollow" shape="rect" class="yiv0673440985gmail_msg" ymailto="mailto:swift-evolution@swift.org" target="_blank" href="mailto:swift-evolution@swift.org" id="yui_3_16_0_ym19_1_1481450784930_3727">swift-evolution@swift.org</a></div><br clear="none" class="yiv0673440985gmail_msg">
<a rel="nofollow" shape="rect" class="yiv0673440985gmail_msg" target="_blank" href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><div class="yiv0673440985yqt5691517778" id="yiv0673440985yqtfd88831"><br clear="none" class="yiv0673440985gmail_msg">
</div></blockquote></div></div></div><br><br></div> </div> </div> </div></div></body></html>