If protocols can (1) store data (2) implement methods (3) force "subclasses" to implement methods, then I'm ok that it isn't spelled "abstract". And yes, I know 2 and 3 done.
-- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On Nov 2, 2017, at 10:07 PM, Gwendal Roué via swift-evolution > <swift-evolution@swift.org> wrote: > > >> Le 3 nov. 2017 à 04:29, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
