<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 13:30, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Feb 20, 2017, at 3:42 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">The proposal I preferred was to use only the public and private keywords and use parameters to provide greater specificity, like so:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>as it is now<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private(module)<span class="Apple-tab-span" style="white-space:pre"> </span>equivalent to internal, which is private to the current module/project<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private(file)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>equivalent to fileprivate<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private(scope)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>equivalent to current private<br class=""></blockquote><br class="">We considered this last year and decided it was a bad idea. The `private` keyword ends up just being surplusage—it just adds noise without adding meaning.<br class=""></div></div></blockquote><div><br class=""></div><div>It may not add a lot of meaning as such, but personally I find it a lot cleaner; everything other than public <b class="">is</b> a form of privacy by module, file etc., so it makes a lot of sense to me to have them grouped in that way. The current keywords are also inconsistent; we have public, private, internal and fileprivate, only one of these is a conjoined keyword, and internal isn't any less a form of privacy than private and fileprivate.</div><div><br class=""></div><div>I also disagree that it adds noise; to me I find the above easier to read, as private tells me that the property/method is being restricted in some way, and I can look at the parameters to find out more (if there are any). Bear in mind that most of the time developers will still only use public, private and nothing at all (the private(module) default), they only need to add the parameter when something more unusual is required.</div><div><br class=""></div><div>In fact, it's one argument for the reduction in keywords, as in my experience I very rarely see anyone actually use internal, usually they just omit the keyword, so most of the time it is a waste to define it, and internal might be nice to have available as a variable name rather than reserved as a keyword that most people rarely, if ever, use. Part of my concern is that there are a number of proposals on the list at the moment that may seek to add new keywords, so trimming this down is useful. It's also a very easy change to migrate; fileprivate becomes private(file), internal becomes private(module).</div><div><br class=""></div><div>I'd also argue that private(module) is clearer in meaning than internal, and private(scope) is much clearer in meaning that just private, though I'm currently undecided of which should be the default for private without parameters.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">it's something else to rename things all across the language for the sake of renaming them.</div></div></blockquote><br class=""></div><div>I think it's unfair to say it's just "for the sake of renaming them"; I feel it's a more consistent and more future proof scheme that cuts down on the number of keywords required, and I also find it easier to read.</div></body></html>