Coming in late, but: * “internal”, as already mentioned, has prior art as meaning “private to a package/project”, so should stay as it is * fileprivate looks good, obvious, straightforward and googlable to me * private(file) introduces a bunch of visual noise that I don't like * whoo-hoo, this discussion is impossible to read through — the power of bike-shedding!
A. > On Mar 18, 2016, at 7:46 PM, Ilya Belenkiy via swift-evolution > <[email protected]> wrote: > > It looks like people finished the discussion for the best access level names. > How should I update the proposal? > > On Mon, Mar 14, 2016 at 8:18 PM Chris Lattner via swift-evolution > <[email protected] <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
