[swift-evolution] Idea: Public Access Modifier Respected in Type Definition

Vladimir.S svabox at gmail.com
Mon Oct 2 05:25:28 CDT 2017


On 01.10.2017 1:18, Chris Lattner wrote:
> 
>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Vladimir, I agree with you on that change, but it’s a separate topic from this one.
>>
>> Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.
> 
> Agreed.  The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.

So we have to live with *protected* extension inconsistency for very long time just 
because core team don't want to even discuss _this particular_ inconsistency(when 
access level in *private extension* must be private, not fileprivate)?

Yes, we decided that access level for extension will mean a default and top most 
access level for nested methods, OK. But even in this rule, which already differ from 
access modifiers for types, we have another one special case for 'private extension'.

Don't you think this is not normal situation and actually there IMO can't be any 
reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 
seems like is a last moment to fix this)

Vladimir.

> 
> -Chris
> 
> 


More information about the swift-evolution mailing list