[swift-evolution] [Review] SE-0026 Abstract classes and methods

[Alsey Miller]

So that is what it boils down to then. So you believe that this change is necessary so that:

class ContreteClass: SuperClass, AbstractProtocol { … }

becomes

class ContreteClass: AbstractClass { … }

?

It is my humble opinion that if this is the core advantage of this proposal, it should not be accepted. This is a major change in the language, not just a small new feature to be added, and if it can be done with existing functionality (like protocols) then at least it should be postponed for future review for Swift 4. For the sake of discussion lets say this does has its advantages, lets put that in the context of Swift 3 development.

Pros:
- Easier Syntax

Cons:
- Already possible with a little different syntax. Nonetheless, if you use protocols properly the EXACT functionality can be achieved. The compiler WILL force you to write an implementation for a protocol.
- Again, protocols are shared between structs and classes, its a syntax unifier to use protocols. With a language that uses structs for 97% of its Standard Library, protocols seem as a better idea for the sake of clarity and unity. Each new feature has o be learned by all Swift programmers. Why add a different syntax (that has to be learned) for existing functionality, when protocols are shared between value and reference types?
- Will disrupt stabilization of Swift 3, should be postponed for Swift 4 since its a mejor language change

If you could provide an example of functionality this proposal will implement, that cannot be achieved currently in Swift, then I believe it would be worth it to introduce such a major new syntax, only for classes.

	Coleman,


> On Mar 3, 2016, at 4:26 PM, Evan Maloney <emaloney at gilt.com> wrote:
> 
>> On Mar 3, 2016, at 4:21 PM, Matthew Judge <matthew.judge at gmail.com> wrote:
>> 
>> Not necessarily commenting for or against abstract classes, but the following logic confuses me:
>> 
>> "ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.
>> 
>> Protocols can't do this, because if you forget to declare conformance with the protocol, the compiler can't enforce anything. This pushes what could be caught at compile-time to a runtime (potentially crashing) problem."
>> 
>> What is the difference between forgetting to declare conformance to a protocol and forgetting to subclass an abstract class? An abstract class, ON ITS OWN, cannot force a class to do anything unless that class declares itself a subclass of the abstract class.
> 
> It's the difference between forgetting to do two things and forgetting to do just one.
> 
> Let's say I have a framework that requires me to supply a subclass of Foo to do something useful.
> 
> With abstract classes, I just need to subclass Foo, and the compiler tells me what implementations I need to provide.
> 
> With the protocol-based "solution" being proposed, I need to subclass Foo *and* I need to remember to declare conformance to FooProtocol. Then and only then can the compiler enforce anything.
> 
> 2 != 1
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/71823c6b/attachment.html>