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

[Ilya Belenkiy]

After replying and seeing it in code, it felt so wrong, that I am updating
the proposal now. It should be Inner only.

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

> That is not clear to me in the proposal.  The proposal states: "When a
> function or a property is defined with `private` access modifier, it is
> visible only within that lexical scope." The most immediate lexical scope
> for innerVar would be Inner.
>
> I'm not advocating either way, just that it be clear in the proposal.
>
> On Mon, Mar 28, 2016 at 7:48 AM, Ilya Belenkiy <ilya.belenkiy at gmail.com>
> wrote:
>
>> 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/4732a122/attachment.html>