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

[Ilya Belenkiy]

Matthew, please take a look at my example with functions (it works today).
In terms of scope, it should be the same with classes. I updated the
proposal to restrict private to the immediate scope, so with the update, it
will be Inner. Please take a look at the proposal. I tried to be very clear
about both the meaning and motivation in the proposal example.

On Mon, Mar 28, 2016 at 8:58 AM Matthew Johnson <matthew at anandabits.com>
wrote:

>
>
> Sent from my iPad
>
> On Mar 28, 2016, at 6:48 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Outer
>
>
> Why Outer?  It looks to me like the enclosing lexical scope is Inner, thus
> innerVar would *not* be visible in Outer, it would only be visible in Inner.
>
>
> 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
>>>>
>>>> _______________________________________________
> 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/decddd73/attachment.html>