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 <[email protected]> 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 <[email protected]> > wrote: > >> 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
