<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I don't believe these two worlds are in conflict at all.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">We currently have the default only state (without overrides), plus a conflict. We would simply be adding "override" functionality in part to clear the conflict.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">With POP the idea is that the protocol, in knowing about how it is constituted, has a clear pattern for how it implements its behaviours. Therefore you can leverage the protocol to bear the brunt of the work, just as we do now.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">The additional tweak to the design of protocols is to allow a user to define their own implementation where the default is not appropriate, or is incomplete for the use case. This doesn't work against POP - it simply observes that implementations at times may need to be customised to the use case, and allows that, as an optional override. It's clear people are trying to do this already because they already have overrides that are causing this conflict, and thus we are having the discussion.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">In this case, I don't see overriding the protocol "default" as working against this world - I think it clarifies it.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Rod</div><div><br>On 11 Feb 2017, at 11:39 am, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>In a vacuum I'd have thought your idea to be superior in terms of consistency and user-friendliness. In that world, protocols are strictly a list of requirements and (optionally) defaults for those requirements.<br><br>In _this_ world, I think the idea is that protocols provide both behaviors and customization points; not all customization points have default behaviors, of course, but also not all behaviors are customizable defaults (what we're discussing here). I can see how that's more sophisticated but also more tricky. I don't see how such a model can be rolled back now that we already have it, though.<br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 10, 2017 at 17:50 Rod Brown <<a href="mailto:rodney.brown6@icloud.com">rodney.brown6@icloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg">I agree this is a very... tricky part of Swift, and that many have stated it is expected behaviour.</div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg"><br class="gmail_msg"></div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg">I think this is fundamentally incorrect from a design standpoint with the concept of a protocol as an agreed interface, rather than an agreed implementation. By adding a Protocol Extensions, we have started to mix implementation with interface, which is understandable as those with the same interface often conform to the same behaviour.</div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg"><br class="gmail_msg"></div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg">That said, I think if my conforming to the protocol means I need to do extra work for my specific implementation case, then letting someone circumvent that by simply referring to me as the protocol is both dangerous and lets the protocol's extension implementation have mixed priority. My unique use case should be more important than the implementation that makes sense for the generic case.</div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg"><br class="gmail_msg"></div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg">My view is protocol extensions should a "default", nothing more. If you implement, you override. This behaviour preserves protocols as an agreed interface with additional default logic rather than a conflicting set of implementations.</div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg"><br class="gmail_msg"></div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg">I think I've stated this view before and been shot down, but I'm not sure.</div></div><div dir="auto" class="gmail_msg"><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg"><br class="gmail_msg"></div><div id="m_7170554739808615397AppleMailSignature" class="gmail_msg">Rod</div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On 11 Feb 2017, at 9:54 am, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Robert, this is a tricky part of Swift. I raised the same point in my very first email to this list a year and a half ago, and the response was that no default/implement/override keyword was desired and that this behavior is intentional. It has since been raised multiple times on this list to the same conclusion.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The idea here is that protocol extension methods that are not protocol requirements are statically dispatched and can be shadowed but not overridden. If you read through some of the Swift-Evolution proposals, you'll see that there are several designs that actually seek to take advantage of this behavior. I can't recall which of these were actually implemented in that way, but it does indeed show that the behavior has its uses.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Many have suggested some sort of keyword to distinguish overriding and shadowing. However, every such proposed design thus far breaks retroactive conformance in some subtle way. It's hard to search the archives, but there are hundreds of emails on this topic.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Fri, Feb 10, 2017 at 15:57 Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg">I remain very unconvinced that type casting should change code being executed...<br class="gmail_msg"><br class="gmail_msg">Sent from my iPhone</div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On 10 Feb 2017, at 21:04, David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 10, 2017, at 12:41 PM, Robert Ryan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div></blockquote><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">I’m hard pressed to think of a situation where you’d want the current Swift 3 behavior of the first example (where you can override a protocol default implementation but you only want that override used when you reference the class itself, but not when you reference the protocol as a type). </div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div>Thats easy - the extension methods are not related to protocol conformance. The type implementing the protocol may not even know there *is* an extension method, or that method could be added either later or by yet other third party code. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As such, the type may not be overriding the extension method at all - the protocol-implementing types may have their own method with a conflicting name doing similar (or not) logic. It would not be appropriate for someone calling the protocol extension method to get different behavior simply because a type declared a similar named method.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In other words, without the method being declared on the protocol, override behavior between an extension and type would be similar to unsafe “duck” typing. There is no agreement by the type that they are conforming to extension behavior, only to the protocol’s behavior.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">IMHO the issue actually goes the other way</div><div class="gmail_msg"> - there is no way to indicate that an extension method to a protocol is meant to declare ‘default’ behavior, e.g. represents a partial implementation for types conforming to the protocol.</div><div class="gmail_msg"> - there is no way to indicate that a type property/method ‘implements’ the functionality of a protocol. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The lack of a distinction between extensions declaring random methods and declaring default implementation behavior is obviously an element of confusion. Both points become an issue if the protocol method signatures ever changes - the extension could no longer be providing a default implementation, or a type may silently switch from their own implementation to the default implementation provided by the extension.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-DW</div><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">If there are such examples, then add a “build setting” to allow you to turn off this warning, or add some keyword to the declaration of the default implementation that indicates that you’re allowing it to be overridden, but protocol types won’t use it (e.g. <span style="color:rgb(186,45,162);font-family:Menlo;font-size:11px" class="gmail_msg">nondynamic</span>). Personally, I’d just add the warning and call it a day (because I don’t know why you’d ever want the current Swift 3 behavior).</div><div class="gmail_msg"><br class="gmail_msg"></div></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>
</div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div></blockquote></div>
</div></blockquote></body></html>