(Though calling "super" and Implementing non-public methods would round out "protocol as abstract class" functionality.)
-- 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 3, 2017, at 8:33 AM, C. Keith Ray via swift-evolution > <swift-evolution@swift.org> wrote: > > 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution