Is there any update on this?
It's still a feature I'd love to see and I don't think it doesn't fit to Swift's design as a protocol-oriented language. In the original rejection note, it says "deferred for Swift 3".
So why not open the discussion again and possibly implement it now?
I'd rather prefer see Swift improve protocols so that it can do everything mixins/traits can rather than abstract classes.
IMO abstract classes are not a good move for Swift: I saw people emulating this behaviour because they thought they needed it. But only because their design was wrong. Good architecture would have allow them to avoid it. Introducing abstract classes would just let them think that they're doing it the right way.
@fredpi, when coming back to very old topics, please do readers the courtesy of starting a new thread and linking to the relevant old discussions; try to give a succinct summary of the points already made so far so that discussion doesn’t start from zero all over again.
Posts that say “I like this; what’s going on?” take almost no effort to write, but they demand anyone who answers to put in an extraordinary amount of work or else rehash what’s already been said.
I'm asking for abstract classes, methods and properties since before Swift 1.0 and even more after it was open-sourced. The response usually is something like "object oriented programming is dead, deal with it". I think we still can have the best of OOP and the best of POP (protocol oriented programming) in Swift. And I'd like to be able to write a real abstract method instead of func myPrettyAndAbstractFunc() { fatalError("Abstract method") }. So a great +1 here. :)
Personally if protocols had support for stuff like properties (mixins), generic existentials and a way to resolve clashing conformances, I'd be happy to remove subclasses from @non-objc class.
And if we also had a way to specify structs / enums reference values (i.e. with Box) I'd be fine with removing @non-objc class altogether.