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

[Ilya Belenkiy]

Outer

On Mon, Mar 28, 2016 at 7:30 AM Matthew Judge <matthew.judge at gmail.com>
wrote:

> 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/115b63f1/attachment.html>