<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2016, at 2:30 AM, Tommaso Piazza via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div style="background-color: rgb(255, 255, 255); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" class=""><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr" class="">Hello Derrick,</div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr" class=""><br class=""></div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr" class="">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" class=""><br class=""></div><div id="yui_3_16_0_ym19_1_1481450784930_3681" dir="ltr" class="">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></div></div></blockquote><br class=""></div><div>This was intentional:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift/commit/a15c485193c4dcb61c330be8c2d869758fff2c45" class="">https://github.com/apple/swift/commit/a15c485193c4dcb61c330be8c2d869758fff2c45</a></div><div><br class=""></div><div>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.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>