<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>FWIW, Ceylon uses only a lexical access level like in the proposal (as I understood it):</div><div><br></div><div><ul style="margin: 0.2em 1.5em 0.2em 0px; padding: 0px 0px 0px 1.5em; border: 0px; vertical-align: baseline;"><li style="margin: 0.3em 0px; padding: 0px; border: 0px; font-style: inherit; vertical-align: baseline;"><span style="background-color: rgba(255, 255, 255, 0);">program elements which are visible only inside the scope in which they are defined, and</span></li><li style="margin: 0.3em 0px; padding: 0px; border: 0px; font-style: inherit; vertical-align: baseline;"><span style="background-color: rgba(255, 255, 255, 0);">program elements which are visible wherever the thing they belong to (a type, package, or module) is visible.</span></li></ul></div><div><br></div><div>In Ceylon this level is called "shared".</div><div><br></div><div>-Thorsten </div><div><br>Am 29.03.2016 um 16:24 schrieb Paul Ossenbruggen via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Just as context is used for variable names does not need a specific scoping specifier every time one is declared. You know from the context in which it is used that it only applies to a certain scope. </div><div class=""><div class=""><br class=""></div><div class=""><div class="">I would hope that if namespaces are added we would not have namespaceprivate etc The keywords would explode and become quite confusing..Instead if it is in a namespace you would use internal or external and the scope changes to the namespace rather than the file but as I said this is beyond the intent of this proposal. </div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 29, 2016, at 7:04 AM, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">How is flexibility desirable?<div class=""><div class=""><br class=""><div class="">Why is it important to me, if I decide that a given class should only be visible at 'internal' scope, that the meaning of 'internal' should be subject to change in future versions of Swift? 'Once you know its meaning' should mean once!</div><div class=""><br class=""></div><div class="">Right now, I use the word 'private' when I want code to be only visible within a file. When I migrate a project to Swift 3, an automatic migrator may not be able to tell whether a given private property should now be scope-private or file-private. Perhaps we can assume that anything private referred to in more than one scope should be file-private and everything remaining should be scope-private, but I think it would still be wise to manually review the changes. Using 'internal' to replace 'private' may make that process even more complicated... but okay, it's a one-time cost.</div><div class=""><br class=""></div><div class="">I don't see the advantage in knowing that adding another visibility level in future will require another intensive review. I'd prefer it if a keyword was explicit about its meaning. Migration can then be straightforward: everything 'private' now can become 'file-private', and if I want to reduce the visibility of anything to scope-private then I can do so manually. If we add an even more private level in future then the code doesn't break just because 'private' was too subjective in its meaning.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 29, 2016 at 2:23 PM, Paul Ossenbruggen 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"><div style="word-wrap:break-word" class=""><span 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></span><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 class=""><br class=""></div><div class="">- Paul</div><div class=""><br class=""></div></div><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="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></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>