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

Ilya Belenkiy ilya.belenkiy at gmail.com
Mon Mar 28 13:40:54 CDT 2016 

> I *still* don't understand your reasoning here. If a private member can
be used in a member function, and in closures inside that member function,
why can't it be used in a member type?

The simplest answer is that it's the most private access level, and also
one that doesn't create any confusion. We already discussed several times
here whether inner should have access to outer or the other way around.
With this design, the answer is neither.

A longer answer is that if you move a function into a type and make it a
member function, you change the semantics. It's no longer the same
function. If you move the type inside another type, the semantics is the
same. The only difference is that we get shorter names. Also, if you move a
function to be a member function, that changes the class API. If you move a
class to become a nested class, that does not change the outer class API.
Both classes can be used the same way but with different spelling of the
name of the inner class.

Also, I think that the terminology of access level really comes from OOP.
The problem with the current state of things is that it mixes this
terminology with export levels. This proposal makes "private" mean what it
means in OOP and extends it so that it makes sense with Swift extensions.

If we were talking about "scoped" level access, the immediate scope
addition would be wrong. But if we are talking about "private", it's a
different matter.

On Mon, Mar 28, 2016 at 1:38 PM Jordan Rose <jordan_rose at apple.com> wrote:

> I *still* don't understand your reasoning here. If a private member can
> be used in a member function, and in closures inside that member function,
> why can't it be used in a member type?
>
> I don't have a notion of "immediate lexical scope". Nothing else in Swift
> is only visible in the "immediate" level of curly-braces.
>
> (This doesn't mean that everything can *successfully* be referenced from
> an inner scope; for instance, a local type declared in a function cannot
> capture local variables or 'self'. But there's a technical limitation
> there, and even *with* that you still find those names via name lookup.)
>
> I am actively against this form of the proposal (regardless of names) and
> I'm sorry I didn't notice the intent here the first time around.
>
> Jordan
>
>
> On Mar 28, 2016, at 6:06, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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
>>
>> _______________________________________________
> 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/22ad0490/attachment.html>

More information about the swift-evolution mailing list