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

[Ilya Belenkiy]

The discussion was about the other direction: whether a nested class should
have access to private members of the outer class.

On Thu, Mar 24, 2016 at 9:35 AM Matthew Johnson <matthew at anandabits.com>
wrote:

>
>
> Sent from my iPad
>
> On Mar 24, 2016, at 5:07 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> It's very consistent with other keywords. I wish compound keywords were
> joined with a dash or something that made them easier to read, but I guess
> it's too late now. If we have associatedtype, it makes sense to use
> moduleprivate (I saw that the name associatedtype was discussed extensively
> but didn't participate in the discussion; I am sure that it was given a lot
> of thought). If we could change this, I'd suggest keyword names with dashes
> everywhere, but if not, these names work well and is a great compromise for
> everything I've seen in this thread.
>
> I am not worried about the length because the 2 most frequently written
> keywords would be public and private. Moduleprivate is the default, and
> file private will not be used as often as private.
>
> One question: should the proposal be explicit about access control for
> nested classes? We discussed it here briefly (I wanted private to be
> completely private to the class or extension itself while 2 other people
> wanted a nested class to have access to the outer class.)
>
>
> I don't think it would make sense at all to allow an outer type to see
> private members of a nested class.  That would break the semantics of
> private meaning "containing scope".
>
> However, with Chris's suggestion of using identifiers as parameters, maybe
> we could eventually have something like private(OuterTypeName) to specify
> the precise level of access desired.
>
>
> On Thu, Mar 24, 2016 at 1:13 AM Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> <responding to several posts in this thread at once>
>>
>> On Mar 14, 2016, at 5: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.
>>
>> What we do with private setters is orthogonal from this proposal, so I’m
>> going to ignore it in this thread.  After SE-0025 is resolved, it would be
>> great to have another thread/proposal that discusses reskinning
>> private(set) - presumably as just a modifier on the setter.
>>
>> Similarly, this proposal has nothing to do with “protected” or any other
>> type based access control, so I don’t delve into that at all either.
>>
>> I’ve seen several proposals that seem promising:
>>
>> On Mar 14, 2016, at 5:49 PM, James Berry <jberry at rogueorbit.com> wrote:
>> > I like fileprivate, if that’s the only change. On the other hand, if we
>> want to consider a broader change, what about:
>> >
>> >       private                 symbol visible within the current
>> declaration (class, extension, etc).
>> >       private(module) symbol visible within the current module.
>> >       private(file)           symbol visible within the current file.
>>
>> I love how this establishes a family with different levels of access
>> control, and unites them under the idea of "levels of being private”.  I
>> also like how people would commonly only ever write public and private
>> (because “private(module)” is the default, and "private(file)" is
>> obscure).  However, parenthesized modifiers that take a keyword (as opposed
>> to an identifier) are a bit weird and awkward, so it would be nice to avoid
>> them if possible.
>>
>> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> > public
>> > private-module
>> > private-file
>> > private
>>
>> This follows the same sort of structure as James’ proposal, without the
>> parens.  It has the same advantages, but trades them with hyphenated decl
>> modifiers.  We don’t do that, but it is a good direction.
>>
>> How about we continue this trend, and follow other existing Swift
>> keywords that merge two lowercase words (associatedtype, typealias, etc),
>> and use:
>>
>>         public
>>         moduleprivate
>>         fileprivate
>>         private
>>
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward
>> parenthesized keyword approach.
>> 4) The unusual ones would be “googable”.
>> 5) Support for named submodules could be “dropped in” by putting the
>> submodule name/path in parens: private(foo.bar.baz) or
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>> natural than putting keywords in parens.
>>
>> What do you all think?
>>
>> -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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160324/203b2a14/attachment.html>