<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Coming in late, but:</div><div class=""><br class=""></div><div class="">* “internal”, as already mentioned, has prior art as meaning “private to a package/project”, so should stay as it is</div><div class="">* fileprivate looks good, obvious, straightforward and googlable to me</div><div class="">* private(file) introduces a bunch of visual noise that I don't like</div><div class="">* whoo-hoo, this discussion is impossible to read through — the power of bike-shedding!</div><div class=""><br class=""></div><div class="">A.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 18, 2016, at 7:46 PM, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">It looks like people finished the discussion for the best access level names. How should I update the proposal?</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Mar 14, 2016 at 8:18 PM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></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 class="">
<br class="">
To summarize the place we’d like to end up:<br class="">
<br class="">
- “public” -> symbol visible outside the current module.<br class="">
- “internal” -> symbol visible within the current module.<br class="">
- unknown -> symbol visible within the current file.<br class="">
- “private” -> symbol visible within the current declaration (class, extension, etc).<br class="">
<br class="">
The rationale here is that this aligns Swift with common art seen in other languages, and that many people using private today don’t *want* visibility out of their current declaration. It also encourages “extension oriented programming”, at least it will when some of the other restrictions on extensions are lifted. We discussed dropping the third one entirely, but think it *is* a useful and important level of access control, and when/if we ever get the ability to write unit tests inside of the file that defines the functionality, they will be a nicer solution to @testable.<br class="">
<br class="">
The thing we need to know is what the spelling should be for the third one. Off hand, perhaps:<br class="">
<br class="">
fileprivate<br class="">
private(file)<br class="">
internal(file)<br class="">
fileaccessible<br class="">
etc<br class="">
<br class="">
Some other thoughts on the choice:<br class="">
- this will be a declaration modifier, so it will not “burn” a keyword.<br class="">
- if will be a uniquely Swift thing, so there is virtue in it being a googlable keyword.<br class="">
<br class="">
Thoughts appreciated.<br class="">
<br class="">
-Chris<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>