<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Em sex, 1 de abr de 2016 às 01:31, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">With these names we lose consistency. The current scheme makes it very clear that each next level is a subset of the previous level. With "internal", fileprivate looks out of place.<div><br></div><div>We have several goals for all the names:</div><div>1) obvious</div><div>2) using standard terms</div><div>3) short</div><div>4) consistent</div><div><br></div><div>This discussion shows that we cannot have all of them. We have to pick something at the expense of something else.</div><div><br></div><div>For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that with this order</div><div><br></div><div>public</div><div>moduleprivate</div><div>fileprivate</div><div>private</div><div><br></div><div>is the best so far.</div><div><br></div><div>public</div><div>internal</div><div>fileprivate</div><div>private</div><div><br></div><div>is not as consistent. It's also not as obvious, given that many people proposed to use internal to mean fileprivate. The biggest advantages of these names are that there is less change and short words. If these are the most important goals, then my original proposal is even better:</div><div><br></div><div>public</div><div>internal</div><div>private</div><div>scoped</div><div><br></div></div></blockquote><div><br></div><div>For me this is good, keep untouched the actual public/internal/private and just add a new word for the new access level.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>It's a non-breaking change, everything retains its meaning, the added name is very clear, and all the names are very short. The biggest problem here is "private" -- it's not the most private that the language provides, and most people would expect that.</div><div><br></div><div>Here is another one like that (it solves the "private" problem at the expense of using non-standard terms):<br></div><div><br></div><div>public</div><div>internal</div><div>local</div><div>scoped</div><div><br></div><div>My main point is that we cannot have everything. We have to pick the order of importance. </div><div><br></div><div>We heard many times that "short" is not the goal of Swift. Instead, it's clarity. If this is the case, then I think</div><div><br></div><div><span><div style="color:rgb(0,0,0)">public</div><div style="color:rgb(0,0,0)">moduleprivate</div><div style="color:rgb(0,0,0)">fileprivate</div><div style="color:rgb(0,0,0)">private</div></span><br></div><div>is the clearest we've seen. Nobody could possibly be confused about the meaning of these names. I doubt that moduleprivate will be required to spell out in any style guide, but even so, it's not so bad. We have many frequently used class names that are much longer.</div></div><div dir="ltr"><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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">On Mar 23, 2016, at 10:13 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br>
> How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:<br>
><br>
> public<br>
> moduleprivate<br>
> fileprivate<br>
> private<br>
><br>
> The advantages, as I see them are:<br>
> 1) We keep public and private meaning the “right” and “obvious” things.<br>
> 2) The declmodifiers “read” correctly.<br>
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.<br>
> 4) The unusual ones would be “googable”.<br>
> 5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). Putting an identifier in the parens is much more natural than putting keywords in parens.<br>
<br>
I’ve seen a number of concerns on this list about moduleprivate, and how it penalizes folks who want to explicitly write their access control. I’ve come to think that there is yes-another possible path forward here (which I haven’t seen mentioned so far):<br>
<br>
public<br>
internal<br>
fileprivate<br>
private<br>
<br>
The advantages, as I see them are:<br>
1) We keep public and private meaning the “right” and “obvious” things.<br>
2) The declmodifiers “read” correctly.<br>
3) Compared to Swift 2, there is almost no change. The only thing that changes is that some uses of Swift 2 “private” will be migrated to “fileprivate”, which makes the intent of the code much more clear.<br>
4) fileprivate is the unusual and not-really-precedented-in-other-languages modifier, and it would still be “googable”.<br>
5) The addresses the “excessively long” declmodifier problem that several people are concerned with.<br>
6) Support for named submodules could be “dropped in” by parameterizing “internal”.<br>
<br>
Thoughts?<br>
<br>
-Chris<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>