> On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution > <swift-evolution@swift.org> wrote: > > I, too, prefer it to be more like this: > > public // unchanged > module // currently internal > internal // currently private > private // new hotness
I like these best out of what’s been suggested so far. I agree with those that think the parameterized versions are too long and unnecessary. —CK > > l8r > Sean > > >> On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution >> <swift-evolution@swift.org> 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 >>> <swift-evolution@swift.org> 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 >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
