<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 20 Feb 2017, at 12:27, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Orthogonal extensions, such as 'protected', multiply the problem. How do you restrict which access levels get 'type' access?</div></div></div></blockquote><div><br class=""></div><div>Well, I was really just mentioning it as a future possibility, I hadn't quite gotten as deciding exactly how type would be used. It's still a form of privacy so I expect it would be grouped under private(type), with the caveat that if the type is public then any private(type) methods and properties will be available to external sub-classes.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">Perhaps, by default:</div><div class=""><br class=""></div><div class="">These four are equivalent:</div><div class="">var someValue: Int = 0</div><div class="">private var someValue: Int = 0</div><div class="">private(module) var someValue: Int = 0</div><div class="">private(get: module) var someValue: Int = 0</div><div class=""><br class=""></div><div class="">'set' defaults to 'get' level unless explicitly restricted further, e.g. these two are equivalent</div><div class="">private(set: file) var someValue: Int = 0</div><div class="">private(get: module, set: file) var someValue: Int = 0</div><div class=""><br class=""></div><div class="">Perhaps 'type' access is 'set' level unless explicitly exposed:</div><div class="">private(get: file, set: scope, type: module)</div><div class=""><br class=""></div><div class="">... It doesn't make sense to me that 'type' would be more restricted than 'set', but offhand I haven't figured out if 'type' can be more exposed than 'get'. If there are restrictions like this the compiler can complain that the access levels specified are inconsistent.</div><div class=""><br class=""></div><div class="">This still seems a bit clunky to me if you have a public and a private on the same line, but perhaps someone can suggest something for that.</div></div></blockquote><div><br class=""></div><div>This is what I had in mind; i.e- you don't <b class="">have</b> to parameterise private, you'd only do it if you want something other than the default.</div><div><br class=""></div><div>As for something with both public and private modifiers (only really applies to properties I think?) I think it's fine to just declare each separately, as there may in future be more public parameters so it makes sense to have the separate grouping of a property's public and private components.</div><div><br class=""></div><div>I'm not clear on your use of private(type:module), what do you see that as representing? Personally I'd just expect them to be used like private(module, type), i.e- the method/property is private but accessible by both module and (externally) by sub-classes.</div><div><br class=""></div><blockquote type="cite" class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">On Mon, Feb 20, 2017 at 11:42 AM, Haravikk via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:</div></div><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="">So discussion of the exact naming convention for access modifiers has been discussed multiple times, especially when fileprivate was being introduced. It's now been a while since fileprivate was added, so we've all had more time to actually work with it, so I wanted to raise the discussion again to see what people now think.<div class=""><br class=""></div><div class="">Specifically, during the debate over access modifiers I really didn't like the propose fileprivate, as I don't like conjoined lower-case key-"words" (to me a keyword should always be a single word, I still don't like associatetype or typealias either, and neither does macOS' auto-correct 😉). And to be honest my opinion hasn't changed; if anything I hate it even more.</div><div class=""><br class=""></div><div class="">The proposal I preferred was to use only the public and private keywords and use parameters to provide greater specificity, like so:</div><div class=""><br class=""></div><div class=""><span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>public<span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>as it is now</div><div class=""><span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>private(module)<span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>equivalent to internal, which is private to the current module/project</div><div class=""><span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>private(file)<span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>equivalent to fileprivate</div><div class=""><span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>private(scope)<span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>equivalent to current private</div><div class=""><br class=""></div><div class="">The actual parameters are up for debate, but I still feel this a lot clearer. I also generally prefer the parameterised version for several reasons:</div><div class=""><br class=""></div><div class=""><ul class="m_6992110101845618359MailOutline"><li class="">Readability: I know not everyone will agree on this one, but I much prefer the separation to having conjoined keywords.</li><li class="">Fewer Keywords: Maybe I'm a keyword purist or something, but I just don't like having too many keywords in the language, especially four for what amounts to a single feature (access).</li><li class="">Extensibility: It is easier and cleaner to add more parameters in future. For example, private(type) could be an equivalent to protected access in other languages. It can also be used to more easily group external extension modifiers under public such as public(final), public(open) etc.</li></ul><div class=""><br class=""></div><div class="">For setter-specific access it might look something like:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="m_6992110101845618359Apple-tab-span" style="white-space:pre-wrap"> </span>private(file:set) var someValue:Int = 0</font></div><div class=""><br class=""></div></div><div class="">I know it might not seem that important to some people, but this is one area of Swift's syntax that still bothers me, perhaps unreasonably so, but I don't get to pick what annoys me! I'd also seek to replace associatedtype and typealias (and any other conjoined keyword I've forgotten) but I haven't thought of any alternatives that I like for those yet.</div><div class=""><br class=""></div><div class="">Anyway, just wanted to discuss how others felt having used fileprivate and such for a while, and whether it's worth revisiting, or if I just have to live with it.</div></div></blockquote></div></div></blockquote></blockquote></div><br class=""></body></html>