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 <[email protected]> wrote: > > > Sent from my iPad > > On Mar 28, 2016, at 6:48 AM, Ilya Belenkiy via swift-evolution < > [email protected]> 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 <[email protected]> > wrote: > >> On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy <[email protected]> >> 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 <[email protected]> >>> 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 < >>>> [email protected]> wrote: >>>> >>>> >>>> On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution < >>>> [email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
