<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I think there is a legitimate hole around abstract methods.<div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">- Karl</div><div class=""><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6. Nov 2017, at 03:43, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">At least SR-103 is a legitimate bug that we would like to fix one day.<div class=""><br class=""></div><div class="">Slava<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 5, 2017, at 1:27 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class="">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: <a href="https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302" class="">https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302</a> and <a href="https://bugs.swift.org/browse/SR-103" class="">https://bugs.swift.org/browse/SR-103</a> and <a href="https://bugs.swift.org/plugins/servlet/mobile#issue/SR-584" class="">https://bugs.swift.org/plugins/servlet/mobile#issue/SR-584</a>)</div><div class=""><br class=""></div><div class="">References:</div><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><a href="https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future" class="">https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future</a> </span></font></div><div class=""><a href="https://www.raizlabs.com/dev/2016/12/swift-method-dispatch/" style="background-color: rgba(255, 255, 255, 0);" class="">https://www.raizlabs.com/dev/2016/12/swift-method-dispatch</a></div><div class=""><br class=""></div><div class=""><div class="">Sent from my iPhone</div><div class=""><br class="">On 5 Nov 2017, at 01:08, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class=""></span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Sent from my iPhone</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Protocols define requirements, they don’t “add” things to the conforming type</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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)?</span><br class=""></blockquote><span class=""></span><br class=""><span class="">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.</span><br class=""><span class=""></span><br class=""><span class="">Slava</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><span class=""></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>