<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 11:14 AM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I just want a name that is:<div class=""><br class=""></div><div class="">- a single English language word</div><div class="">- whose common meaning has something to do with privacy, access, permissions, or a similar grouping concept that the other three keywords fits into </div><div class="">- and intuitively describes the intensity of the behavior relative to the other three keywords</div></div></div></blockquote><div><br class=""></div><div>I think everyone would like that. But nobody has been able to come up with a word that doesn’t have problems of one kind or another (for the new access level or for the file access level).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I'm not sure if this is something we want to reopen, though, or what the right process would be.</div></div></div></blockquote><div><br class=""></div><div>This has received a vast amount of bike shedding already. I would like to see us continue with the implementation of SE-0025. If anyone thinks they have found a way to improve the naming a new proposal can be put forward. If an obviously better name is suggested I will support such a proposal enthusiastically!</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 29, 2016 at 9:10 AM, Matthew Johnson 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=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 11:06 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">On Wed, Jun 29, 2016 at 11:03 AM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><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=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 10:55 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" 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="">On Wed, Jun 29, 2016 at 10:52 AM, Matthew Johnson via swift-evolution<span class=""> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 10:46 AM, Sean Heber <<a href="mailto:sean@fifthace.com" target="_blank" class="">sean@fifthace.com</a>> wrote:</div><br 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=""><br class="">On Jun 29, 2016, at 10:22 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 29, 2016, at 10:08 AM, David Hart <<a href="mailto:david@hartbit.com" target="_blank" class="">david@hartbit.com</a>> wrote:<br class=""><br class="">Sorry if I wasn’t expressing myself well enough. In my original email, I said that:<br class=""><br class=""><blockquote type="cite" class="">The new rules make `private` more prominent compared to `fileprivate` (the latter has a somewhat worse name).<br class=""></blockquote><br class="">So I agree that my issue is more with the naming than the functionality. I’m mainly complaining that because of its name, `fileprivate` feels like more of a special corner case of `private`. But in the style of writing types through extensions, `fileprivate` will become much more prevalent than `private`, which feels slightly backwards.<br class=""></blockquote><br class="">I don’t view it as more of a special corner case at all, but I can see why you feel that way since it has an unprecedented (AFAIK) and more verbose name. <br class=""><br class="">The proposal originally left `private` alone and used a new name for the new access level. We weren’t able to find a name that didn’t have problems which led to the idea of renaming the existing `private`.<br class=""><br class="">My perspective is that it’s just the best name we could come up with for the concept in the context of the various access levels we want to support. The name isn’t intended to discourage use in any way. <br class=""></blockquote><br 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=""><span 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;float:none;display:inline!important" class="">It may not be intended, but that doesn’t mean it won’t, though. :P</span><br 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=""><br 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=""><span 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;float:none;display:inline!important" class="">I can’t say exactly *why*, but I feel similar to David here in that “fileprivate” is such an… odd… name that I’m inclined to just not use it and let things default to “internal” instead. In fact, I have *already* caught myself doing this. I don’t know if that’s *bad* exactly (would more things being internal actually aid the compiler/optimizer?),<span class=""> </span></span></div></blockquote><div class=""><br class=""></div></span><div class="">I’m pretty sure more things being internal will not help the optimizer. In fact, if you are not compiling with WMO turned on it could prevent optimizations.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><span 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;float:none;display:inline!important" class="">but I think this is a valid concern. The issue here is rooted in psychology, not technology. :/</span><br 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></blockquote><div class=""><br class=""></div></span><div class="">That’s a fair perspective. But a *significant* amount of time was spent bike shedding this. I’m not sure whether you and David participated or not, but that was the time to have the naming discussion.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think the case being made here is that `fileprivate` was settled on when it was thought that it would be rarely used. With what's emerged in this discussion, it turns out that `fileprivate` might be more useful than previously thought, and the awkwardness of the name therefore is more troublesome than when the naming discussion first took place.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">The example in this thread (placing data members in the type declaration and methods in extensions) is one that received ample discussion during the earlier threads and the review.</div><div class=""><br class=""></div><div class="">I don’t know that `fileprivate` will be used in code more commonly than previously thought. The issue is about the default access level of members inside a `private` type (i.e. when access is *not* directly specified). With Jordan’s proposed solution, `fileprivate` will be used to describe these members in documentation and diagnostics. </div><div class=""><br class=""></div><div class="">It will also be possible to state this default explicitly, but I don’t think that will be too common. This is the only change in what is possible to do *in code* from the original proposal.</div></div></div></blockquote><div class=""><br class=""></div><div class="">You're adding words to my argument that I didn't put there. I didn't specify "in code". Awkward is awkward, in code or in documentation.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That wasn’t intentional, sorry. I misunderstood and thought you meant it would be used more frequently in code than previously thought. Thanks for clarifying.</div><div class=""><br class=""></div><div class="">I certainly don’t oppose a better name if anyone can suggest one that is clearly better. But I am skeptical that this is possible given the amount of bike shedding that has already happened.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div 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=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">IMO the value of having more control over visibility far outweighs a slightly awkward name for file level visibility. I don’t think it’s anywhere near awkward enough to avoid, but I suppose YMMV.</div><br class=""><blockquote type="cite" class=""><div class=""><br 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=""><span 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;float:none;display:inline!important" class="">l8r</span><br 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=""><span 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;float:none;display:inline!important" class="">Sean</span></div></blockquote></div><br class=""></div><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></blockquote></div></div></div></div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></span></div><br class=""></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=""></body></html>