> On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution > <[email protected]> wrote: > > Another +1 for James' idea to use private(module), private(file), private: > - It avoids ambiguity whether internal/private/local is more restrictive and > replaces it with a single axis, public vs. private. > - The two longer terms, private(module) and private(file), are the least used > ones. > - As mentioned by Joe, it admits clean extension to groupings between file > and modules in the future (e.g. submodules). > > The only question is (as Sean mentioned) how this combines with the syntax > for setter access level, e.g. the current private(set). Options: > - Unnamed 2nd argument, giving private(file), private(file, set), > private(set).
We could conceivably reskin private(set) too. A lot of people complain it's "weird" as-is, for better or worse. -Joe > - Named 2nd argument, giving e.g. private(file), private(file, accessor: > set), private(accessor: set). Less ambiguity but longer. > - Not using multiple arguments, but that'd probably break consistency with > the other unification efforts going on to make everything look like function > calls. > > > On Tue, Mar 15, 2016 at 1:42 PM, Sean Heber via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > 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] > > <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> > >>> https://lists.swift.org/mailman/listinfo/swift-evolution > >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >> > >> _______________________________________________ > >> swift-evolution mailing list > >> [email protected] <mailto:[email protected]> > >> https://lists.swift.org/mailman/listinfo/swift-evolution > >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
