<div dir="ltr">+1 to all of Goffredo's comments.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 4 March 2016 at 18:41, Goffredo Marocchi via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Brent, why is dynamic dispatching for protocol extension default implementations wrong in your mind? Wouldn't you agree that when static dispatching introduces such a side effect that it should not be automatically applied and perhaps a keyword should be added if you really wanted static dispatching nonetheless?<br>
<br>
I think that code execution should not be affected by type casting, it feels like a very confusing part of the language.<br>
<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
On 4 Mar 2016, at 07:06, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> (B) and (C) could be mitigated by shadowing warnings, and we've also floated ideas for making them behave as intended, by implicitly forwarding protocol requirements into class methods to address (B) and/or introducing dynamic dispatch for protocol extensions to address (C).<br>
><br>
> For what it's worth, I've posted threads several times aimed at addressing (C) through better warnings and keywording, and each time I've gotten lost of feedback from people who just want it dynamically dispatched. I wasn't aware of (B), but my guess is that I'd have heard the same thing if I'd brought it up.<br>
><br>
>> - Adopting an explicit 'implements' modifier, in the spirit of 'override', to mark a declaration as being intended to fulfill a requirement. This adds boilerplate we'd like to avoid, and also interferes with retroactive modeling.<br>
><br>
> One possible way around that second issue is to permit you to mark the conformance itself as `implements` when you're doing retroactive modeling.<br>
><br>
> protocol Arithmetic {<br>
> func + (lhs: Self, rhs: Self) -> Self<br>
> func - (lhs: Self, rhs: Self) -> Self<br>
> func * (lhs: Self, rhs: Self) -> Self<br>
> func / (lhs: Self, rhs: Self) -> Self<br>
> }<br>
><br>
> extension Int: implements Arithmetic {}<br>
> extension Double: implements Arithmetic {}<br>
><br>
> If we just turned off the keyword requirement when the conformance was marked, people would abuse the feature, so perhaps it merely indicates that one or more members defined *outside* the current module implement the requirements. Any members *inside* the current module would still have to be individually marked. (And if the protocol wasn't at least partially implemented by external members, the `implements` in the conformance would be illegal.)<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><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>
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>
</div></div></blockquote></div><br></div>