[swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Charles Srstka cocoadev at charlessoft.com
Thu Jul 21 16:46:26 CDT 2016


> On Jul 21, 2016, at 2:29 PM, Karl via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On 21 Jul 2016, at 20:49, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>> 
>> On Jul 21, 2016, at 8:56 AM, Karl <razielim at gmail.com <mailto:razielim at gmail.com>> wrote:
>>> 
>>> Just posted in the Review #2 thread. I read the updated proposal, and I have another idea besides making “final” default:
>> 
>> Hi Karl,
>> 
>> Please respond to proposal on this thread with your evaluation of it.  This isn’t the right place to make counterproposals.
>> 
>> -Chris
> 
> -1 from me. Same reasons as before, I think:

I’m -1 as well, for the reasons that have already been given, but since it’s clear that this thing’s going to be rammed down our throats no matter how we feel about it, we might as well try to make lemonade:

> First proposal:
> - Conflation of ‘public’ and ‘open’; it feels like open is a new higher access level, like getting married, or going sudo or something. If this proposal was accepted, ‘open' should substitute ‘public’, and never be alongside it (the same way “public private class” makes no sense)

Actually, if ‘public’ and ‘open’ are separated, it might allow us to finally have some sort of ‘protected’ access level. ‘private open’ implies something that can be subclassed but not otherwise accessed, which would more or less provide ‘protected’ functionality.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/d0de4f3e/attachment.html>


More information about the swift-evolution mailing list