[swift-evolution] [Review] SE-0026 Abstract classes and methods

Gwendal Roué gwendal.roue at gmail.com
Fri Mar 4 13:27:57 CST 2016

> Le 4 mars 2016 à 20:24, Gwendal Roué <gwendal.roue at gmail.com> a écrit :
>> Le 4 mars 2016 à 08:45, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> a écrit :
>>> For modeling subtype requirements we would need the ability to declare protocol members with reduced access scope like private or internal and hopefully protected, as subtype requirements most often are not public.
>> I've spoken about this elsewhere, but:
>> - For both abstract classes and protocols, all required/abstract members need to be visible everywhere you're permitted to conform/inherit.
>> - There is currently no way in Swift to decouple a protocol's/class's visibility from the ability to conform to/inherit from it, so neither construct can currently offer this feature.
>> - However, this feature is likely to come at least for classes as part of resiliency. I think it's a good idea for protocols, too.
> Brent, please consider the sample code below:

I just wanted to put focus on the visibility issues, which you could not see (it seems). Your general arguments about ways to improve protocols so that not only classes could be enhanced remain quite valid and inspiring.


More information about the swift-evolution mailing list