I'd be keenly interested in something that would improve the experience of conforming a type to a protocol. I think others would as well. A sufficiently sophisticated solution would:<br><br>* catch unintentional typos that cause required functions to be incorrectly named<br>* show, ideally prospectively, which required functions have default implementations<br>* clarify (and this is obviously a cherry-on-top scenario) what protocol requirements any particular function helps to satisfy as well as which combination of implementations is used to synthesize a default implementation of another function (e.g. <= synthesized from < and ==; this would help to determine whether it might be more efficient to roll your own override)<br>* support all retroactive modeling scenarios currently supported<br><br>I tried to propose a keyword-based solution (less sophisticated than yours) a while back, and I've been convinced that the drawbacks in terms of decreased expressiveness in retroactive modeling might be insurmountable. Perhaps it would be worthwhile exploring improvements in tooling and documentation (including annotation of the code itself) in order to address some of these areas?<br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 29, 2016 at 09:14 Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">On Apr 28, 2016, at 10:00 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:<br><div><blockquote type="cite">Hi, Erica. Sorry for not participating in the first round here. I’m…not so happy with this direction, for a number of reasons. (I apologize for the laundry list, but they’re not really related complaints.)<br><div><div style="word-wrap:break-word"><br>- ‘required’ already means something today: it means “this initializer must be present on all subclasses”. The reason it only applies to initializers is because all other members are always present on all subclasses.<br><br>(Counter-argument: using ‘required’ on an initializer could be seen as making an implicit protocol, just for that class hierarchy.)<br><br>- ‘override’ likewise already has a meaning; allowing ‘override’ to be satisfied by a protocol requirement means that it might miss an override intended for a superclass—or inadvertently become one when an SDK is updated.<br><br>(Counter-argument: that last can happen to protocols already.)<br><br>- This doesn’t cover cases where methods in one protocol extension satisfy requirements in another.<br><br>- This doesn’t cover retroactive modeling.<br><br>- I’m not sure what it means to "prefer an overridden implementation in preference in reverse hierarchical order: type extensions take precedence over type declarations over protocol extensions over protocol declarations (assuming protocol declarations eventually adopt default implementations)”. Protocol conformance is decided at compile time; there won’t ever be any members in type extensions that take precedent over a type declaration without causing a conflict. (That is, currently you are not allowed to define such a member.)<br><br>- A member in the type does <i>not</i> “override" a member in a protocol extension today, because such a call is not dynamically dispatched. Making protocol extension members dynamically dispatched is challenging at the least and would require an implementation plan in the proposal.<br><br>- Thank you for writing up all of the source compatibility cases! I <i>think</i> there’s no issue with binary compatibility, since IIUC the proposal doesn’t change how anything is implemented, and we think we know how to handle binary compatibility there. But I’d like to think about it a little more.<br><br>- The “A.foo(self)()” syntax is clever, but it doesn’t work correctly for mutating methods (because you can’t curry an inout). On the other hand, JoeG already brought up the idea of making ‘self’ the first argument of the implicit static member. It still doesn’t solve the problem of <i>picking</i> a protocol extension, but that’s not new. (This isn’t a complaint, I guess, just a note.)<br><br><br>I’m not sure I have a meaningful summary or conclusion, but I’d be hesitant to do all of this without these concerns being addressed.<br><br>Jordan</div></div></blockquote></div><br></div><div style="word-wrap:break-word"><div>I've arrived at the "just table it and find something more productive to work on" stage. This pitch grew out of my conviction that doing "near miss" detection was the wrong approach for supporting and documenting developer intent decisions. If there's no strong support my the core concept (enhancing safety by introducing semantic compiler hints) then all the implementation details in the world don't get me anywhere.</div><div><br></div><div>Without developing a quorum that supports the underlying philosophy, regardless of implementation, I'm not going to push this any further. The gist is updated but I have no plans to further mold it into a proposal.</div></div><div style="word-wrap:break-word"><div><br></div><div>-- E</div><div><br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div>