What color is your bikeshed? I don't suppose you'd consider swapping private and internal (since the opposite of public is private, and internal means inside)?
Anyway, there's fileScoped (or filescoped), access(file) (which has the option of being used for access with module and global), filedelimited, filefixed, filebounded, filebound, filerestricted. You may want constructing phrases around bounding, restrictions, access, limitations, visibility, and local. -- E > On Mar 14, 2016, at 6: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
