[swift-evolution] SE-0025: Scoped Access Level, next steps

[Shawn Erickson]

On Mon, Mar 14, 2016 at 8:36 PM Patrick Pijnappel via swift-evolution <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <sean at fifthace.com> 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 <
>> swift-evolution at 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 at 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 at swift.org
>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>
>> >> _______________________________________________
>> >> swift-evolution mailing list
>> >> swift-evolution at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160315/a8f128b2/attachment.html>