+1

I like this a lot. Name ideas : enclosed, filelocal, fileonly, filelock, 
fileaccess, fileprivate, insidefile, inner. I also like Erica’s filebound & 
file fixed.

By Erica’s suggestion about switching…

- public
- modular, modulelock, packaged  (module only)
- internal (file only)
- private

Designer . Developer .  Nerd 
Jo Albright


> On Mar 14, 2016, at 8:18 PM, Chris Lattner via swift-evolution 
> <[email protected]> wrote:
> 
> Per Doug’s email, the core team agrees we should make a change here, but 
> would like some bikeshedding to happen on the replacement name for private.
> 
> To summarize the place we’d like to end up:
> 
> - “public” -> symbol visible outside the current module.
> - “internal” -> symbol visible within the current module.
> - unknown -> symbol visible within the current file.
> - “private” -> symbol visible within the current declaration (class, 
> extension, etc).
> 
> The rationale here is that this aligns Swift with common art seen in other 
> languages, and that many people using private today don’t *want* visibility 
> out of their current declaration.  It also encourages “extension oriented 
> programming”, at least it will when some of the other restrictions on 
> extensions are lifted.  We discussed dropping the third one entirely, but 
> think it *is* a useful and important level of access control, and when/if we 
> ever get the ability to write unit tests inside of the file that defines the 
> functionality, they will be a nicer solution to @testable.
> 
> The thing we need to know is what the spelling should be for the third one.  
> Off hand, perhaps:
> 
> fileprivate
> private(file)
> internal(file)
> fileaccessible
> etc
> 
> Some other thoughts on the choice: 
> - this will be a declaration modifier, so it will not “burn” a keyword.
> - if will be a uniquely Swift thing, so there is virtue in it being a 
> googlable keyword.
> 
> Thoughts appreciated.
> 
> -Chris
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to