Although really, why not just use “file” instead of “internal” since it won’t burn any keywords or cause any other conflicts as far as I know.
l8r Sean > On Mar 14, 2016, at 9:38 PM, Sean Heber <[email protected]> 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
