Generally I’m in favor of dropping “internal” as being somewhat vague, and moving forward with module and fileprivate.
public module fileprivate (also google friendly) private > On Mar 15, 2016, at 5:32 PM, Charles Kissinger via swift-evolution > <[email protected]> wrote: > >> >> On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution >> <[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 > > 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 >>> <[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> David James
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
