<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Per Doug’s email, the core team agrees we should make a change here, but would like some bikeshedding to happen on the replacement name for private.<br>
<br>
To summarize the place we’d like to end up:<br>
<br>
- “public” -> symbol visible outside the current module.<br>
- “internal” -> symbol visible within the current module.<br>
- unknown -> symbol visible within the current file.<br>
- “private” -> symbol visible within the current declaration (class, extension, etc).<br></blockquote><div><br></div><div>Very much like the thinking.</div><div><br></div><div>I guess it isn't feasible at this point to change `internal` to mean file scoped? That could avoid the need for another qualifier by simply leveraging the default of module scope for things without an access qualifier. </div><div><br></div><div>As you know the default of whole module means most developers need never use access control unless they desire to reduce access scope (e.g. file scope, dec scoped). Those working on frameworks would be the ones to leverage public in addition to the other levels.</div><div><br></div><div>Of the top of my head: ` pubic`, `internal` (and `internal(module`)), `internal(file)`, `private`. This makes public and private being closest to other languages as you noted with internal being more swift nuanced.</div><div><br></div><div>-Shawn </div></div></div>