<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=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">The issue is that if I want to include another framework, and that framework has also defined it (or more likely relies on another framework that defines it) then swift gets upset about the multiple definitions. I really<span class="Apple-converted-space"> </span><i class="">want</i><span class="Apple-converted-space"> </span>to rely on those libraries, but if it makes my own framework have a danger of conflicts with other libraries then it will stop adoption of my framework as a result.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">This hasn't stopped a number of others from relying on types they've defined, like the Result type, for example.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Things like Result can be differentiated by the module name in case of conflict. That isn’t possible with operators.</div><div class=""><br class=""></div><div class=""><div class="">Also, there are now two versions of AlamoFire which need to be kept in sync depending on which Result type they use.</div></div></div></div></div></blockquote><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>There’s exactly one version of Alamofire. Anyone maintaining a fork that uses another Result type does so on their own time without support from the Alamofire project itself. </div><span class="Apple-tab-span" style="white-space:pre"> </span>That said, this is a major pain in the ass. About once a year we get a request from someone for us to use the antitypical Result type instead of our own. We reject it because we don’t want dependencies in such a highly used library. So users have to go through the trouble of either bridging between the two types or using some fork. It’s further complicated by the fact that in Alamofire 4 / Swift 3 we switched to Result<T> instead of Result<T, E>, since we deal with generic Errors from the underlying URLSession APIs most of the time. That makes the bridging that much more complicated. But manual differentiation can be tricky to make work, there were some unexpected gotchas. <div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>So, do the 500,000+ combined installs of Alamofire and Result qualify this type for inclusion in the standard library yet?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon</div></body></html>