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

[Matthew Judge]

On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
wrote:

> lexical scope is the other way around: "inner" can see "outer". For
> example:
>
> func f() {
>   let outer = 0
>  // f cannot use inner
>    func g() {
>        let inner = 1
>        // g can use outer
>    }
> }
>
>
Maybe I'm off in my terminology, but I think my code example matches what
you are saying here (outer is visible to g() but inner is not visible to f()


> It would work the same way for the access level. That said, I'd rather not
> include this in the proposal.
>

So as the proposal stands now, what is the scope that innerVar is visible
to in the following code: Inner or Outer?

class Outer {
    class Inner {
        private var innerVar: Int
    }
}


> The only change that the core team requested was the name changes. I
> personally would prefer a completely private version where you cannot
> inject a class into a scope to get access to the scope internals, but it's
> an edge case that could be argued either way, and I don't want to start
> another lengthy discussion. We already had quite a few.
>
> On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge <matthew.judge at gmail.com>
> wrote:
>
>> I know it was suggested that it be the subject of a different thread, but
>> it might be good to clarify how the new private is going to work (or at
>> least what is currently envisioned).
>>
>> My understanding is that the new private would be:
>> - visible only to the immediately enclosing scope
>> - including the scope of a inner nested scope
>> - not including the scope of an outer nested scope
>> - not visible to an extension
>>
>> Said in code (all in the same file):
>> ----------
>> class Outer { // Outer visible to module
>>     private var a: Int // visible to Outer, Inner1, & Inner2
>>
>>     class Inner1 { // Inner1 visible to module
>>         private var b: Int // visible to Inner1 only
>>     }
>>     private class Inner2 { // visible to Outer & Inner(s)
>>         var c: Int // visible to Outer & Inner(s)
>>     }
>> }
>>
>> extension Outer { // visible to module
>>     // 'a', 'b', and 'Inner2' NOT visible
>> }
>> ----------
>> If this is the intended meaning of private, then fileprivate seems to be
>> the same as private (private to the enclosing scope... which happens to be
>> the file).
>>
>> Something declared "private" at the top level of a file is fileprivate.
>> There would still need to be a way to reference scopes other than the
>> immediate one (especially since there is no way to say "private" and mean
>> moduleprivate), though I think it would strengthen the argument for
>> something along the lines of "private(file)", since it would even further
>> reduce the cases where you are spelling something more than just "private"
>>
>>
>> On Mar 27, 2016, at 17:31, Haravikk via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Public
>> External (default)
>> Internal
>> Private
>>
>>
>> I still feel like these are still too vague; I’m not sure I like the use
>> of external, as public to me is external since it exports outside of the
>> module, whereas what you’re proposing is in fact just limited to the module
>> itself. I dislike the current internal keyword too, but at least it reads
>> as “internal to this module", this is why the more specific terms are
>> better like:
>>
>> public as-is, item is public/exported outside of module
>> private(module) or private current internal, item is private to this
>> module, would be the default
>> private(file) current private, item is private to this file
>> private(scope) new visibility type, item is private to the current scope
>>
>> Assuming I’m understanding the restriction properly this time =)
>>
>> It’s also the easiest method if we do add another visibility later for
>> sub-classes such as private(type), as it doesn’t even require a new keyword.
>>
>> _______________________________________________
>>
>>
>> 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/20160328/9dbd7e58/attachment.html>