> On May 22, 2016, at 3:38 PM, Brent Royal-Gordon <[email protected]> > 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.
That’s pretty extreme. I’m curious - does this still bite you now that you understand the behavior? Or are you mostly concerned about users who don’t really understand how the language works? > >> (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. :^) Lol. That would be terrible! There are very good implementation reasons for the behavior of protocol extension methods. There would be no such justification with classes. IMO `final` should mean final, period. > >> 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. Sure, I admit it’s not great. This is a pretty tricky naming problem! > > 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. Yeah, I don’t think `virtual` has a place in Swift. > > 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. I agree `final` is kind of close, but not close enough. It has a very precise meaning and I prefer to keep it that way. > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
