<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I'm kind of late to this thread, so if my argument has been brought up before, please just ignore me:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I know naming the modifiers `module` and `file` have been suggested already, and those were dismissed as being to broadly named. Would these modifiers stand on their own, I'd agree with this in full. However, access modifiers always accompany something like `let`, `class`, `func` etc.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">To give some examples:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"> module class Worker { ... }</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">This, to me, sounds exactly like what it would be: A class belonging to the module.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"> file let apiURL = "<a href="https://api.example.com/">https://api.example.com/</a>"</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Again, imho this describes what it is perfectly: A constant belonging to the current file.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Extending this to the new private and to public, I think `public` fits reasonably well, and for the new private, something along the lines of `scope` could work well:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"> scope func myUtilityFunction() { ... }</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">– Lukas</div><div id="AppleMailSignature"><br></div><div>On 29 Mar 2016, at 13:09, Paul Ossenbruggen via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>If someone sees public and external in different places while learning the language they would be curious to see what the difference is. <span style="background-color: rgba(255, 255, 255, 0);">The first time I saw internal in swift, I looked it up. It was not immediately apparent from the name what it meant from then on, there was no confusion. This similarly would apply to external. </span></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Since the C extern is a different word, I would not assume it is the same, but may be not that confusing, as it is used in a similar manner to C. You are exposing the item beyond this file. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Since external is the default, it would not be seen as often. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">These specifiers should be single words because they are typed quite often. I think public is the single most word I typed on a library I created. Since they will be seen a lot they should be pleasing to the eye. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I would be ok with "shared" for external but I like the symmetry of internal-external and public-private. Does it then become shared-excluded? Shared-unshared? Still like external-internal better. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">- Paul </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Sent from my iPhone</div><div><br>On Mar 29, 2016, at 9:31 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">I agree with Ilya that "external" is too easy to confuse with "public", especially given the specifier "extern" in C. Additionally, we think we can get away with renaming "private" because most current uses of "private" (file-scoped) declarations are within the same (brace-bound) scope anyway; "internal" could potentially cause a lot more churn. And as Andrey pointed out, we'd be at odds with C#, the only other language that uses "internal" as an access specifier today.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 29, 2016, at 7:03 , 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="">-1, "external" can be also understood as "exported" or public. I think that the names in the updated proposal are the clearest. Also, I think that at this point we need to stop trying to come up with more names. I don't think that we will ever reach a point where everybody is happy with the names. The ones that we have now seems to be a good compromise that is in line with other Swift keywords.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen 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"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="">public (unchanged)</div><div class="">external (module access)</div><div class="">internal (file access)</div><div class="">private (scoped access)</div></blockquote></div><div class=""><div class=""><br class=""></div></div><div class="">This seems logical and something I could live with, but how is it better than moduleprivate and fileprivate? Also, internal has contradictory prior art in C# and Swift 2 (not that it stops us).</div><div class=""><br class=""></div><div class="">And I see the length of moduleprivate and fileprivate as a feature, and external/internal lacks it.</div></div></div></div></div></blockquote></div><div class=""><br class=""></div></div><div style="word-wrap:break-word" class=""><div class="">It is better than moduleprivate and fileprivate in that it is a single word which is easier to to read and there is less typing. Less typing even with autocomplete is a benefit. Once you know its meaning, that both are relative to file access, you won’t have to look it up. Also, just noticed this, when I type multiword keywords in an email program or chat program autocorrect butts in. This is of practical value because much work is done in chat and email programs. </div><div class=""><br class=""></div><div class="">Simpler is better if it sufficiently conveys the meaning and it does in this case. The expectation with most keywords are that they be single words, especially ones that are used the most. </div><div class=""><br class=""></div><div class="">There is a nice symmetry to internal/external and public/private.</div><div class=""><br class=""></div><div class="">If external/internal refer to the file, then we don’t need the multiword descriptive versions. Also, if we decide later that scoping to namespaces is desired these same already reserved keywords give us more flexibility than the more specific keywords would allow. Internal/external could refer to the namespace scope rather than the file scope if it is inside a namespace (this is beyond the scope of the proposal but trying to think ahead). By not explicitly stating the scope you gain flexibility </div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">- Paul</div><div class=""><br class=""></div></div>_______________________________________________<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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>