<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 class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md</a> ]</div><div class=""><br class=""></div><div class="">I’m pretty concerned about completely removing this feature. Yes, it’s a type-checker / decl-checker nightmare, but I think Paolo’s example in the initial discussion showed how it’s being used effectively today. I’d much rather have some kind of inference marker that maps one-to-one between an associated type and a value requirement (method, initializer, property, or subscript), also as brought up in the original discussion. </div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">protocol OptionA {</div><div class=""> associatedtype Index</div><div class=""><br class=""></div><div class=""> @infers(Index)</div><div class=""> var startIndex: Index { get }</div><div class=""><br class=""></div><div class=""> var endIndex: Index { get }</div><div class="">}</div><div class=""><br class=""></div><div class=""><div class="">protocol OptionB {</div><div class=""> @inferredFrom(startIndex) // allows a full name here for overload resolution</div><div class=""> associatedtype Index</div><div class=""><br class=""></div><div class=""> var startIndex: Index { get }</div><div class=""> var endIndex: Index { get }</div><div class="">} </div><div class=""><br class="Apple-interchange-newline">protocol OptionC {</div><div class=""> associatedtype Index in startIndex // sugar</div><div class=""><br class=""></div><div class=""> var startIndex: Index { get }</div><div class=""> var endIndex: Index { get }</div><div class="">}</div></div></blockquote><br class=""><div class="">OptionC is the prettiest, but OptionA is probably the most flexible (consider overloading on associated types).</div><div class=""><br class=""></div><div class="">I know we want to lock down on things now, and I know we can do better in the future, but I think inferring associated types is really quite common, and I’m concerned about taking it out without giving people a good alternative. This <i class="">is</i> just an impression, though.</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>