Any updates on “SE-0026 Abstract classes and methods"?

After looking at the proposals I happily realized that the ability to create abstract classes has been discussed and deferred (not reproved as I had imagined).
But it hasn't been updated since 2016. I imagine it won't come to Swift 5, but is it still on the table or has it been forgotten/found a roadblock at this point?

What advantage are they supposed to bring?

Read the proposal.

Unfortunately, I think that these are never coming. There is quite a resistence to this idea where many will argument that this is better modeled with protocols. In simpler cases, this can indeed be the case - declare a protocol, declare default implementation of some of the methods and create a class conforming to the protocol.

There are, however, annoying things to this approach:

  • you have to redeclare all the variables when implementing the protocol. This is mainly annoying, if you need to achieve 100% of documented symbols due to internal company requirements as you need to re-document the same symbol from the protocol docs, you need to keep both in-sync, etc.
  • if the protocol changes and it changes e.g. name of a method that has a default implementation you won't notice that you have a dead method implemented until runtime (if at all). With abstract classes, you have the override keyword. There have been discussions about a required/opt-in keyword that would mark methods/properties that they are implemented because of a protocol requirement and then in case no protocol requires them, it would result in a warning. But I believe these discussions resulted in a rejection of such an idea.

IIRC @Erica_Sadun had worked on this topic.

But yes, as you say, that's an usability issue and there's been discussions about this. It's not yet a solved issue afaik so you're right on time ^^

It's a topic I continue to be passionate about. I assume that it will be easier to continue the discussion after the stress of WWDC is over.

2 Likes

As @zoul said you can read the specifics in the proposal. But the way I see it, most "solutions" to this are contrived and error-prone.
Maybe it's because of my style, I like to make as many errors as possible detectable on compile time (making everything private for example). So having to create a class and just say "DONT INSTANTIATE THIS" or as @charlieMonroe said, protocols with extensions that will break silently is really bad for me.