[swift-evolution] [Review] SE-0026 Abstract classes and methods
emaloney at gilt.com
Thu Mar 3 15:49:34 CST 2016
> 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 ;)
More information about the swift-evolution