Sorry, I sent too early. Example should have been:<div><br></div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">struct Example<T>: A {</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> func get() -> T {...}</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">}</span></font></div></div><div><br></div><div>My mistake does bring up another question. What if it only conforms after the method is defined, in another module?</div><div><br></div><div>extension Example: A {}<br><br>On Thursday, 28 April 2016, Andrew Bennett <<a href="mailto:cacoyi@gmail.com">cacoyi@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Great proposal, I think it will clear up some mistakes. What happens when it is only an override sometimes? For example:<div><br></div><div>protocol A {</div><div> associatedtype Element</div><div> func get() -> Element</div><div>}<br><div><br></div><div>extension A where Element: ArrayLiteralConvertible {</div><div> <font size="2"><span style="background-color:rgba(255,255,255,0)">func get() -> Element { </span></font><span style="background-color:rgba(255,255,255,0);font-size:small">return [] </span><span style="background-color:rgba(255,255,255,0);font-size:small">}</span></div><div>}</div><div><br></div><div>struct Example<T> {</div><div> func get() -> T</div><div>}</div><div><br></div>Example does "override", but not always. I'm sorry, I couldn't think of a good solution to this.<br><div><br>On Thursday, 28 April 2016, L. Mihalkovic via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div><br>On Apr 27, 2016, at 9:56 PM, Erica Sadun <<a>erica@ericasadun.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Apr 27, 2016, at 1:45 PM, L. Mihalkovic <<a>laurent.mihalkovic@gmail.com</a>> wrote:</div><br><div><div dir="auto"><div>Inline<br><br><div>Regards</div>(From<span> mobile)</span></div><div><br>On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>On Apr 27, 2016, at 12:25 PM, Douglas Gregor <<a>dgregor@apple.com</a>> wrote:<br><div><blockquote type="cite"><br><div><div style="word-wrap:break-word">On Apr 27, 20</div></div></blockquote></div><div><br><blockquote type="cite"><div style="word-wrap:break-word"><div><div><span style="white-space:pre-wrap"> </span>* If the latter, “override” is probably the wrong keyword because it’s not overriding anything in the common case of implementing a non-defaulted requirement.</div></div></div></blockquote><div><br></div>It would be pointless if it’s just satisfying a requirement. That’s why introduced both keywords into the discussion. (And because I’m still being influenced by the “near miss” conversation.)</div><div><br></div></div></blockquote><div><br></div><div>One could always argue that should protocol definitions ever be allowed to contain default implementations ala-java default methods, the distinction between former and latter would go away, and it would be happy anticipation to have mandated *override* all along in all cases, ensuring that future default methods would not accidentally take precedence of current code or wind up being treated differently than other overrides.</div></div></div></blockquote><div><br></div><div>I would expect default implementations in protocol definitions to act exactly like protocol definitions in extensions from the Type point of view.</div><div><br></div><div>From the protocol point of view, I would introduce the same override behavior to signal affirmative intent.</div><br><blockquote type="cite"><div dir="auto"><div></div></div></blockquote></div></div></blockquote><br><div>... so *override* seems like the right keyword choice for today, that would be future proof in case default methods ever make it in protocols (which might be a cheap partial answer to the 'what about mixins' question)</div></div></blockquote></div></div>
</blockquote></div>