I mostly miss this (a.k.a. protected methods): "Protocols don't support language enforcement of separate implementor and user interfaces, since all of a protocol's requirements must be as visible as the conformance. An abstract base class can expose private or internal abstract requirements to its implementation subclasses while exporting a different interface for external users.“
-Thorsten > Am 03.11.2017 um 06:07 schrieb Gwendal Roué via swift-evolution > <[email protected]>: > > >> Le 3 nov. 2017 à 04:29, Brent Royal-Gordon via swift-evolution >> <[email protected]> a écrit : >> >> I think we should beef up protocols a little bit so that they can serve the >> role of abstract classes. > > That would be great. > > Back in the day, the proposal SE-0026 "Abstract classes and methods" was > deferred, with the following rationale: > https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000056.html > > This rationale is great because it lists a few use cases for abstract class > that protocols can't mimic today. > > Gwendal > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
