<div dir="ltr"><div><span style="font-size:13px">        * What is your evaluation of the proposal?</span></div><div>+ 1<br style="font-size:13px"><span style="font-size:13px">        * Is the problem being addressed significant enough to warrant a change to Swift?</span></div><div>Yes. When inference goes wrong it is frustrating and difficult to puzzle out.<br style="font-size:13px"><span style="font-size:13px">        * Does this proposal fit well with the feel and direction of Swift?</span></div><div>Yes. I agree that a keyword for explicitly invoking inference would also work if it meant that the process would be consistent. The ability to add type aliases to protocol extensions is welcome as well.<br style="font-size:13px"><span style="font-size:13px">        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></div><div><span style="font-size:13px">        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br></div><div>A couple readings. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 30, 2016 at 7:23 PM, Jordan Rose via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md</a> ]</div><div><br></div><div>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><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>protocol OptionA {</div><div>  associatedtype Index</div><div><br></div><div>  @infers(Index)</div><div>  var startIndex: Index { get }</div><div><br></div><div>  var endIndex: Index { get }</div><div>}</div><div><br></div><div><div>protocol OptionB {</div><div>  @inferredFrom(startIndex) // allows a full name here for overload resolution</div><div>  associatedtype Index</div><div><br></div><div>  var startIndex: Index { get }</div><div>  var endIndex: Index { get }</div><div>} </div><div><br>protocol OptionC {</div><div>  associatedtype Index in startIndex // sugar</div><div><br></div><div>  var startIndex: Index { get }</div><div>  var endIndex: Index { get }</div><div>}</div></div></blockquote><br><div>OptionC is the prettiest, but OptionA is probably the most flexible (consider overloading on associated types).</div><div><br></div><div>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>is</i> just an impression, though.</div><div><br></div><div>Jordan</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>