I'm in favor of this too. Parameterizing the private syntax is nice, but it introduces complications elsewhere. We should come up with a new word, `module` seems good to me.
Sincerely, Zachary Waldowski [email protected] On Mon, Mar 14, 2016, at 10:38 PM, Sean Heber via swift-evolution wrote: > I, too, prefer it to be more like this: > > public // unchanged > module // currently internal > internal // currently private > private // new hotness > > l8r > Sean > > > > On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution > > <[email protected]> wrote: > > > > +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 > > _______________________________________________ > 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
