<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Jun 28, 2016, at 10:51 PM, Paulo Faria <<a href="mailto:paulo@zewo.io">paulo@zewo.io</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><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><div>This seems very related to the near-miss checking I mentioned in my other reply to Austin. </div><div><br></div><div> - Doug</div><div><br></div></body></html>