[swift-evolution] Proposal: Require explicit modifier for statically dispatched extension methods (was: Universal dynamic dispatch for method calls)
kevin at sb.org
Sat Dec 12 00:31:14 CST 2015
Thank you for writing this up. I have a few concerns:
1. The usage of `final` seems to be conflating class behavior and protocol behavior. Your stated reason for preferring `final` can be summed up as you view Swift from a virtual dispatch worldview, but the keyword doesn't make any sense here when viewed from a static dispatch worldview. I say it doesn't make sense based on the existing meaning of `final`, where it applies to classes only, and restricts subclasses.
2. I also worry that `final` will be confusing when you consider protocol inheritance; if a protocol P has an extension method foo(), and a protocol Q inherits P and also defines foo(), the usage of `final` suggests that should be disallowed when in fact it's perfectly fine.
3. I still don't understand the point of @incoherent. I feel like it's just going to be extra boilerplate that very few people are actually going to understand the reason for, and almost everyone will just add it when the compiler yells at them. Or since you propose not even offering it as a Fix-It, then people will think Swift simply doesn't support having the same method name on a type and on a protocol, and will view that as an annoying limitation.
4. I also think @incoherent only makes any sense at all if you view Swift from a dynamic dispatch worldview (not even virtual dispatch; protocol extensions don't have a virtual function table, so a virtual dispatch view should be fine with current behavior). Which is to say, there's simply no conflict when viewed from a static dispatch worldview. So this attribute is going to be required for everyone, even when we don't see it as being in conflict.
I do think it's valid to say that you can't tell from looking at a protocol extension which methods are default implementations and which ones are new methods that aren't part of the protocol, and that's why I proposed the `default` keyword. But using that keyword also means no @incoherent (because there's no implicit acknowledgement of a "conflict" like with the `final` keyword, it simply seeks to disambiguate which methods are default implementations).
On Thu, Dec 10, 2015, at 02:09 AM, Brent Royal-Gordon wrote:
> > The details of the solution are tricky, but I like this general approach with “final” (or whatever the right keyword is). It passes the smell test for me.
> I’ve written up a draft of about half of a formal proposal at <https://github.com/brentdax/swift-evolution/blob/master/proposals/0000-require-final-on-protocol-extension-methods.md>. It provides a bit more detail and hopefully a more complete rationale for why I favor the design I’ve proposed.
> Brent Royal-Gordon
More information about the swift-evolution