[swift-evolution] Static Dispatch Pitfalls

[Matthew Johnson]

Sent from my iPad

On May 21, 2016, at 4:50 PM, Brent Royal-Gordon <brent at architechies.com> wrote:

>> Making them 'final' causes problems with retroactive modeling.
> 
> Because of that issue, I had an attribute you could use to acknowledge conflicts and disable the error. But this ended up being rather complex: you needed to be able to label a member *or* an extension *or* an import which made a conflicting member and conformance visible in the same place.
> 
> Here's the last draft of the proposal, from way back in December: <https://github.com/brentdax/swift-evolution/blob/final-protocol-methods/proposals/0000-require-final-on-protocol-extension-methods.md>

Now I remember this thread.  Swift evolution was so active at the time that I think I didn't follow it too closely.

The proposal is well thought out and makes a valiant attempt at handling all of the issues necessary.  But I don't support it for a number of reasons.  I think it highlights how awkward it would be to try to address shadowing on a case-by-case basis, which isn't necessarily obvious until you explore what a solution might look like.  (And btw, 'final' in this proposal is not exactly, because when combined with @incoherent the methods are not actually 'final' - there is a necessary escape hatch).

There are two things we should do to help reduce confusion around this.  First, we should allow default implementations in the protocol declaration itself (I believe this is intended and is considered an implement ion limitation right now).  

Second, we should require annotation of methods in protocol extensions that are not default implementation of requirements.  Maybe 'shadowable' or 'staticdispatch'?  These are awkward, but so is the behavior and they describe it better than anything else I've seen so far (maybe we can do better though).

I don't like 'nondynamic' both because it is not aligned with the meaning of 'dynamic' and also because it only says what the behavior *is not* rather than what the behavior *is*.

-Matthew

> 
> -- 
> Brent Royal-Gordon
> Architechies
>