I think there is a legitimate hole around abstract methods. I don’t think it really matters whether you’re talking about a class hierarchy or a protocol hierarchy. They’re both providing partial implementations of behaviour, predicated on some other method being implemented. The practical difference is really about Objective-C interop, and how easily you can reason about method dispatch.
Out of interest: what makes this so challenging to the type-checker? I imagine a naïve implementation which flags methods as requiring implementation by a subclass, marking which classes in a hierarchy have unimplemented methods, and making those initialisers not visible (except to subclasses). Subclasses would also be prevented from calling ‘super’ on methods which the superclass doesn’t implement. I mean, the way I see it, if it can understand the concept of a private initialiser, inaccessible outside of the same type, it already knows about classes which you can’t instantiate. So, roughly I picture this as being a combination of a new visibility level (subclasses only - inferred by the presence of unimplemented abstract methods), plus something which checks all calls to “super” (including initialisers) and makes sure they are implemented. Or is it substantially more complex than that? - Karl > On 6. Nov 2017, at 03:43, Slava Pestov via swift-evolution > <[email protected]> wrote: > > At least SR-103 is a legitimate bug that we would like to fix one day. > > Slava > >> On Nov 5, 2017, at 1:27 AM, Goffredo Marocchi <[email protected] >> <mailto:[email protected]>> wrote: >> >> I would say that you kind of already entered a slippery slope when the >> extension to a protocol can add code / not just declare a behavioural >> contract and how it changes OOP approach (hence: >> https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302 >> <https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302> and >> https://bugs.swift.org/browse/SR-103 <https://bugs.swift.org/browse/SR-103> >> and https://bugs.swift.org/plugins/servlet/mobile#issue/SR-584 >> <https://bugs.swift.org/plugins/servlet/mobile#issue/SR-584>) >> >> References: >> https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future >> <https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future> >> https://www.raizlabs.com/dev/2016/12/swift-method-dispatch >> <https://www.raizlabs.com/dev/2016/12/swift-method-dispatch/> >> >> Sent from my iPhone >> >> On 5 Nov 2017, at 01:08, Slava Pestov <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> >>>> On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>>> On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> Protocols define requirements, they don’t “add” things to the conforming >>>>> type >>>> >>>> I agree with this, but then this warrants a change for protocol extensions >>>> too. Would you be happy with the restriction that default method >>>> implementations are only available for value types and not for classes (as >>>> structs cannot share code any other way, it is the argument for that I >>>> seem to recall)? >>> >>> Protocol extensions are in some sense just syntax sugar for defining new >>> functions. Having a protocol conformance add storage to the conforming type >>> is fundamentally different. >>> >>> Slava >>> >>>> >>>> >>> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
