[swift-evolution] Abstract methods

[Karl Wagner]

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 <swift-evolution at swift.org> 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 <panajev at gmail.com <mailto:panajev at gmail.com>> 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 <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>> 
>>> 
>>> 
>>>> On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi <panajev at gmail.com <mailto:panajev at gmail.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
> 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/20171112/3a82ead1/attachment.html>