On Tue, Mar 15, 2016 at 10:32 AM, Charles Kissinger via swift-evolution < [email protected]> wrote:
> > > On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution < > [email protected]> 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. > > > +1 to this as well. "file" is fine instead of "internal" as well. I don't like the parameterized versions private(file) and private(module) because they can get very verbose (I find I use file access all the time), and because of the already-mentioned concerns about stacking with the private(set) convention. > > > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
