<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 Jun 27, 2016, at 12:56 PM, Dave Abrahams 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=""><br class="">on Sat Jun 25 2016, Austin Zheng <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 25, 2016, at 6:23 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class="">Hi Austin,<br class=""><br class="">I’m sorry to say, but this proposal makes me really sad. I consider<br class="">associated type inference one of the more elegant aspects of Swift.<br class="">It would be very unfortunate to lose it.<br class=""></blockquote><br class="">There are lots of "elegant" things that Swift could do, but has chosen<br class="">not to do for pragmatic reasons (e.g. generalized implicit<br class="">conversions, type inference that crosses statement boundaries). Given<br class="">how terrible the development experience can be right now in the worst<br class="">case, I would happily trade off some measure of convenience for better<br class="">tooling.<br class=""></blockquote><br class="">Well, the type checker's inference engine has *always* been kinda<br class="">unreliable, </div></div></blockquote><div><br class=""></div><div>Dave is dramatically understating the pain that this inference has caused. Because this is the only place we do global type inference, it’s put tremendous pressure on the type checker that caused a huge number of bugs, crashes, and outright incomprehensible behavior. I reimplemented the inference of associated type witnesses in April of 2015 (<a href="https://github.com/apple/swift/commit/126e404fe5bf0be81206f22c83a61f6689d18854" class="">https://github.com/apple/swift/commit/126e404fe5bf0be81206f22c83a61f6689d18854</a>, for reference), when the existing implementation unbearable. It got *far* better, but it’s still not global *enough* to actually be predictable, and the legacy of this mis-feature manifests in a number of weird ways (e.g., typealiases in protocol extensions cannot be used to satisfy associated type requirements, weird rules for when a defaulted associated type gets used).</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">and the experience is made much worse by the lack of<br class="">recursive protocol requirements and the inability to express other<br class="">constraints that would better guide inference, and by the “underscored<br class="">protocols” such as _Indexable that are required to work around those<br class="">limitations. IMO it's premature to remove this feature before the<br class="">inference engine is made sane, the generics features are added, and the<br class="">library is correspondingly cleaned up, because we don't really know what<br class="">the user experience would be.<br class=""></div></div></blockquote><div><br class=""></div><div>Well, there’s a chicken-and-egg problem. The complexity of this inference is getting in the way of other improvements. For example, inference of associated types for conditional conformances requires that associated type witness deduction consider additional requirements, which is a complexity we would entirely avoid</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Finally, I am very concerned that there are protocols such as Collection,<br class="">with many inferrable associated types, and that conforming to these<br class="">protocols could become *much* uglier.<br class=""></div></div></blockquote></div><br class=""><div class="">That’s the general concern I have as well: how much boilerplate does this add? In many cases, we get some of the associated type witnesses for Collection types for free, and I don’t know to what extent we can emulate that with defaulted associated type requirements and typealiases in protocol extensions.</div><div class=""><br class=""></div><div class="">That said, I’ll take some minor regressions in this area for the massive simplification that this proposal brings.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div></body></html>