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

Alsey Miller alseycmiller at gmail.com
Thu Mar 3 15:52:56 CST 2016


Classes are definitely first-class citizens. And I’ll concede that this proposal has its advantages. But I do strongly believe, that in accordance to the roadmap for Swift 3, this should not be accepted, and should instead be introduced in Swift 4. There is a precedence for good proposals being pushed to next year, since Swift 3’s goal is stabilization. 

	Coleman,





> On Mar 3, 2016, at 4:49 PM, Evan Maloney <emaloney at gilt.com> wrote:
> 
>> 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 ;)
> 

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


More information about the swift-evolution mailing list