[swift-evolution] [Proposal draff] abstract classes and methods

[Douglas Gregor]

> On Jan 9, 2016, at 11:02 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 7, 2016, at 9:55 AM, David Scrève via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> # Abstract classes and methods
>> 
>> * Author(s): David Scrève
>> 
>> ## Introduction
>> 
>> When developing framework and reusable, we need to develop classes that are partially 
>> abstract with partial implementation. Protocol and protocol extensions provide this, but 
>> they cannot have attributes as classes have.
>> A partial class combines the behavior of a class with the requirement of implementing methods
>> in inherited class like protocols.
> 
> I tend to agree that adding abstract methods (and classes) is the right thing to do.  OOP is an important part of Swift, and is a great way for modeling certain classes of problems.

I’m not nearly as convinced that it’s worth doing. It’s a small feature with a small win, and I tend to think that protocols are a better answer for most problems for which one would reflexively reach for an abstract class.

> 
> I wonder if we could simplify our initializer model if we had this, for example, could “required" initializers go away?


No, it doesn’t help with required, but the differences between “abstract” and “required” would be sure to cause confusion. “abstract” means “some class along the inheritance path below me must implement this”, whereas “required” means “every class along the inheritance path below me must implement this."

	- Doug