<div dir="ltr">So, just so I'm understanding correctly what the new system would be (taking into account Chris Lattner's comments).<div><br></div><div>A symbol specified as 'public' is visible outside the module.</div><div>A symbol with no specifier, or specified as 'moduleprivate', is visible only within the module, but anywhere within it. This default lets us start coding first and refine visibility later; 'moduleprivate' replaces 'internal'.</div><div>A symbol specified as 'fileprivate' is visible only within the file in which it is declared.</div><div>A symbol specified as 'private' is <i>as private as possible</i> given its type.</div><div><br></div><div>So, if a constant, variable, property, func, enum, struct, etc. is defined inside of a scope, 'private' makes it visible only within that scope. All private properties of a nested inner type are visible throughout the scope of the outer type which contains it, and the inner type can see any private properties in the scope which contains it.</div><div><br></div><div>If a constant, variable, protocol, class etc. is defined outside of a scope, 'private' is synonymous with 'fileprivate'. (I don't know if using 'fileprivate' on a type which cannot be "scope-private" should generate a warning.)</div><div><br></div><div>Extending to the future: if we add any more levels, they must fit within the hierarchy (i.e. all levels must be expressible as concentric rings in a Venn Diagram, no overlapping) and there must be an objective specifier which signifies its visibility.</div><div>So if we add a 'submodule' level, then a submodule must comprise a set of whole files which is a subset of the containing module. A 'submoduleprivate' symbol is visible anywhere in any of the files it consists of - there would be no way to mark part of a file as being within the submodule, and part of the file outside of it.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 30, 2016 at 2:33 PM, David Waite via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I believe we will need another non-type access level if frameworks are ever divided into submodules.<div><br></div><div>-DW</div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Mar 30, 2016, at 7:13 AM, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div>I am not sure if we will ever get another access level. If we do, great, but given how long this discussion has been already, I am not counting on it :-)<br><br>Most likely, if we get more, it will be possible to describe it with a simple word, or a combination of words or with some common abbreviations, so I am not worried about extensibility. I think that the names in the proposal are very consistent with Swift as it is today and will serve us well. They are also completely unambiguous and don't depend on the reading context, so if we come up with other ways to label access levels, it should still be possible to either use these names for backward compatibility or migrate them automatically to new names without any difference in semantics.<br><br>We also needed to pick something. I waited for about a week to get everybody's vote, and I think that I picked a compromise that we can all be at least ok with. (I also originally wanted short single word names). I think we should close the naming thread at this point.<br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge <<a href="mailto:matthew.judge@gmail.com" target="_blank">matthew.judge@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> If Scala style access modifiers were adopted for Swift then a private(file) modifier would also be necessary to give the current private functionality.<br>
><br>
> I could imagine having these options:<br>
><br>
> public // visible to all everyone<br>
> private(scope-name, scope-name, …) // visible to specified scopes (plus current scope)<br>
> private // visible only to current scope<br>
><br>
<br>
Allowing multiple "scope-name"s is a lot of flexibility and power, but not sure it's useful/worthwhile.<br>
<br>
For the current discussion, I would think "scope-name" should be limited to an enclosing scope only. So you can say "private(Outer)" from an Inner class or "private(#file)" from within a class, but not "private(ClassA)" from within ClassB.<br>
<br>
(This would also solve the ambiguity of how to reference the main ClassA or a specific extension to ClassA... "private(ClassA)" can only refer to whichever scope of ClassA you are currently in.)<br>
<br>
> scope-name could perhaps be:<br>
><br>
> * A type name (or Self, which would mimic C++-style private, or perhaps even C++-style protected depending on how we treat inheritance)<br>
<br>
But, this is getting into type-based access which is beyond the scope of SE-0025 right?<br>
<br>
> * A module name (or #module for the current module)<br>
> * A file name string (or #file for the current file)<br>
><br>
> And then the default would simply be `private(#module)`.<br>
><br>
> Alternatively, the parameterized level could be given a different name, like `internal` or `shared`. If that were the case, then `#module` might simply be the default.<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>