On Mon, 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. > It seems to just move the ambiguity under private and muddies the traditional meaning of private compared to other languages IMHO. > - The two longer terms, private(module) and private(file), are the least > used ones. > True-ish except that a large amount of code (at least in swift stdlib) is using `internal` which would be mapped to `private(module)` despite that being the default access level. > - 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). > - Named 2nd argument, giving e.g. private(file), private(file, accessor: > set), private(accessor: set). Less ambiguity but longer. > The questions to me is what if I want the setter to be private to file or module scopes while the getter has a different level of visibility? > On Tue, Mar 15, 2016 at 1:42 PM, Sean Heber via swift-evolution < > [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]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
