How would you handle translating the existing private(set) and the like with this syntax? It seems like it could get confusing and perhaps end up in a situation where you have something like private(file, set) but then you have to constantly remember which order the parameters are in.
l8r Sean > On Mar 14, 2016, at 8:47 PM, Ilya Belenkiy via swift-evolution > <[email protected]> wrote: > > I really like James's idea: > > private symbol visible within the current declaration (class, > extension, etc). > private(module) symbol visible within the current module. > private(file) symbol visible within the current file. > > this is very precise and crystal clear. All other already suggested names > have room for interpretation. These are obvious at a glance. > > On Mon, Mar 14, 2016 at 8:49 PM James Berry via swift-evolution > <[email protected]> wrote: > > > On Mar 14, 2016, at 5: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. > > > I like fileprivate, if that’s the only change. On the other hand, if we want > to consider a broader change, what about: > > private symbol visible within the current declaration > (class, extension, etc). > private(module) symbol visible within the current module. > private(file) symbol visible within the current file. > > James > _______________________________________________ > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
