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
