<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="">I think in the referenced example the new private would mean “class and extensions”, with file being the new private, which I think is confusing.</div><div class=""><br class=""></div><div class="">My preference would be:</div><div class=""><br class=""></div><div class="">public</div>module (currently internal)<div class="">protected (class and extensions)<div class="">private </div><div class=""><br class=""><div class="">protected is widely used to mean this in other languages and fits well semantically between public and private. The other alternative could be just to re-use the class and struct keys; i.e- a “class” accessible property means the class, its descendants and its extensions know about it, with struct being the same for structs (in which case it’s just extensions, so the distinction might be nice for clarity). Alternatively we could re-use the extension keyword, to indicate that the property/method is available to extensions (including sub-classes).</div><br class=""><div><blockquote type="cite" class=""><div class="">On 15 Mar 2016, at 23:40, James Campbell 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 dir="ltr" class="">Just wondering, wouldn't <span style="font-size:12.8px" class="">private be enougth for a class level declaration ?</span><div class=""><br class=""></div><div class="">Not sure why we need a file baed one.</div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><p class=""><b class=""><font color="#cc0000" class="">___________________________________</font></b></p><p class=""><b class="">James⎥Head of Trolls</b></p><p class=""><b class=""><font color="#cc0000" class=""><a href="mailto:james@supmenow.com" target="_blank" class="">james@supmenow.com</a>⎥<a href="http://supmenow.com/" target="_blank" class="">supmenow.com</a></font></b></p><p class=""><b class=""><font size="2" class="">Sup</font></b></p><p class=""><b class=""><font size="2" class="">Runway East
</font></b></p><p class=""><b class=""><font size="2" class="">10 Finsbury Square</font></b></p><p class=""><b class=""><font size="2" class="">London</font></b></p><p class=""><b class=""><font size="2" class="">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div>
<br class=""><div class="gmail_quote">On Tue, Mar 15, 2016 at 12:18 AM, Chris Lattner via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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" 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=""></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=""></div></div></body></html>