[swift-evolution] Static Dispatch Pitfalls

[Xiaodi Wu]

On Sun, May 22, 2016 at 3:38 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > 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.
>
> It does, but I'm just not sure what else you can do about it. If there's a
> warning, you need a way to silence it. If you ignore some cases (like
> creating a conflict by importing two modules), you'll miss some of the
> subtlest and hardest-to-fix bugs.
>
> Honestly, I'm tempted to say "you just can't ever shadow a final protocol
> method" and be done with it. If that prevents certain conformances or stops
> certain imports, so be it. You can always work around that with wrapper
> types or other techniques.
>

You know, I think this might be cleverest solution. It adds a small limit
to the language, but it doesn't unduly penalize retroactive modeling. If
you control either the protocol or the conforming type, you can change the
name of one of the methods so it doesn't shadow/get shadowed by the other.


>
> > (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 is no particular reason you couldn't allow similar annotated
> shadowing of `final` methods on classes; they would have basically the same
> semantics as you get here, where if a piece of code knows it's working with
> the subclass you get subclass semantics, but otherwise you get superclass
> ones. I do not claim this is a good idea. :^)
>
> > 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 think `shadowable` makes sense here; that doesn't acknowledge a
> limitation, which is what we're trying to do here.
>
> I continue to wish we hadn't taken `static` for statically-dispatched type
> methods. But I lost that argument years before swift-evolution became a
> thing.
>
> > 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*.
>
> I do understand what you mean here. Unfortunately, the word "virtual" in a
> keyword makes me break out in hives, and I'm not sure what else we might
> base it on.
>
> This is why I selected `final` in my proposal. `final` is desperately
> close to the actual semantic here, far closer than anything else in the
> language.
>

How about `nonoverridable`? That said, I agree with earlier comments that
training-wheel annotations probably aren't the way to go. Maybe, as you
suggest above, just don't allow shadowing at all.


>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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/20160522/1cad461b/attachment.html>