[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu]

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:

* catch unintentional typos that cause required functions to be incorrectly
named
* show, ideally prospectively, which required functions have default
implementations
* 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)
* support all retroactive modeling scenarios currently supported

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?
On Fri, Apr 29, 2016 at 09:14 Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> On Apr 28, 2016, at 10:00 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>
> 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.)
>
> - ‘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.
>
> (Counter-argument: using ‘required’ on an initializer could be seen as
> making an implicit protocol, just for that class hierarchy.)
>
> - ‘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.
>
> (Counter-argument: that last can happen to protocols already.)
>
> - This doesn’t cover cases where methods in one protocol extension satisfy
> requirements in another.
>
> - This doesn’t cover retroactive modeling.
>
> - 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.)
>
> - A member in the type does *not* “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.
>
> - Thank you for writing up all of the source compatibility cases! I
> *think* 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.
>
> - 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 *picking* a
> protocol extension, but that’s not new. (This isn’t a complaint, I guess,
> just a note.)
>
>
> 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.
>
> Jordan
>
>
> 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.
>
> 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.
>
> -- E
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160429/029196f0/attachment.html>