<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">We also know that the current situation isn’t acceptable to a great proposition of the community, that is why we are still discussing the issue!<div><br></div><div>A notable example of reversal of an evolution decision is String’s conformance to Collection. Which I think on the 2nd attempt was a much better decision. </div><div><br></div><div>For requiring typedefs for associated types, a fix it and error would be quite successful, e.g. Xcode already suggests the typedefs (which I currently accept before letting Xcode insert blanks for the missing methods etc.).<br><br><div id="AppleMailSignature">-- Howard. </div><div><br>On 3 Dec 2017, at 8:15 am, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sat, Dec 2, 2017 at 2:30 PM, Howard Lovatt via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Definitely in favour of doing something, I always define the associated types since I have had so much trouble with the inference.<br>
<br>
Personally I would prefer just 1 and 2 and forget 3. I know this would break a lot of code, but I think we should do that because it is the lesser of the evils.<br></blockquote><div><br></div><div>As Doug wrote, an approach that's essentially that was reviewed and rejected in SE-0108. We already know that it's not acceptable to a great proportion of the community.</div><div><br></div><div><br></div></div></div></div>
</div></blockquote></div></body></html>