<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 29, 2016, at 2:54 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Jun 28, 2016, at 10:51 PM, Paulo Faria <<a href="mailto:paulo@zewo.io" class="">paulo@zewo.io</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 2:48 AM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span 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-stroke-width: 0px; float: none; display: inline !important;" class="">If you tested it, there's a problem with the current behavior independent of associated type inference, and it should be fixed whether or not the proposal is accepted.</span></div></blockquote></div><br class=""><div class="">I don’t think it should be an error. Normally we can have any number of functions with the same name but different return types. By failing in this specific case would be like saying that when you implement a protocol with an associated type you can only return what’s defined in the associated type. I don’t think that should be the behaviour we expect.</div></div></blockquote><br class=""><div class="">This seems very related to the near-miss checking I mentioned in my other reply to Austin. </div><div class=""><br class=""></div><div class=""> - Doug</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">Actually, the more I think about it I get the conclusion that It really shouldn’t be an error. Otherwise this would mean that you wouldn’t be able to use the default implementation and have a function with the same name but returning another type. And if we can’t get an error; We’re just making it easier for the bugs by forcing one to keep the typealias and his own implementation in sync. With inference this wouldn’t exist. This is a really hard one. Looks like the decision is already made. If this is really the case; All I can say is that I really hope this comes back in Swift 4. </div></body></html>