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

[Evan Maloney]

> 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)

But it can't be done with protocols. That's the point.

> - 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.

It's not the same functionality. 

> - 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.

Ah, now we're getting to the crux of it, I think. So, the argument is that because 97% of the Swift standard library is structs, we should not consider any new functionality that is limited to classes?

The reason we're discussing a class-based solution to the problem is that the problem is inherently related to having an inheritance hierarchy.

This is why I keep going back to the fundamental question: are classes not first-class citizens in Swift? Your argument seems to be that they're not.

If they are, however, then I think it warrants a solution that's limited to classes.

> 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?

Because protocols don't provide the feature I seek, no matter how many times people tell me otherwise ;)