[swift-evolution] [Draft] Allow declaration of abstract functions and properties on classes

Pierre Monod-Broca pierre at monod-broca.fr
Mon Feb 29 11:19:24 CST 2016


Ok, 'mutating' was a bad example.

> Le 29 févr. 2016 à 18:14, Gwendal Roué <gwendal.roue at gmail.com> a écrit :
> 
> Yet mutating methods declared in a protocol can be implemented by classes, and are not reserved to structs.
> 
> I think that Evan’s reasoning is the following:
> 
> 1. Swift has classes, and supports class inheritance. It’s a plain fact.
> 2. The concept of "abstract class" is tied to classes, and only classes, since it requires inheritance in its very definition.
> 3. Hence the concept of "abstract class" belongs to the class realm, and protocols have nothing do to with it.
> 
> Gwendal
> 
> 
>> Le 29 févr. 2016 à 17:55, Pierre Monod-Broca via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> I'm not sure it's a problem. By the way, protocols can already have 'mutating' func, which only apply to structs.
>> 
>> 
>>> Le 29 févr. 2016 à 17:47, Evan Maloney via swift-evolution <swift-evolution at swift.org> a écrit :
>>> 
>>>> You can write class-only protocols in Swift.
>>> 
>>> I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
>>> 
>>> The latter would need to needless conceptual leakage.
>>> 
>>> 
>>>> 2016/02/29 11:27、Evan Maloney via swift-evolution <swift-evolution at swift.org> のメッセージ:
>>>> 
>>>>>> I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, I’m starting to agree that this is an important language feature indeed, since I can’t think of any better (or even equivalent) way of solving the example you showed.
>>>>> 
>>>>> I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
>>>>> 
>>>>> Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
>>>>> 
>>>>> It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
>>>>> _______________________________________________
>>>>> 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
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 



More information about the swift-evolution mailing list