Outer 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
