[swift-evolution] Abstract methods

[C. Keith Ray]

(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 at 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 at swift.org> wrote:
>> 
>> 
>>> Le 3 nov. 2017 à 04:29, Brent Royal-Gordon via swift-evolution <swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171103/6aa028d8/attachment.html>