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