<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=""><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="">— It adds no power to the language</div><div class="">The proposal solves no real problem, but rather encourages a certain style of programming, which is quite popular among authors of styleguides, but has no clear net gain.</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">While your other points are defendable, I have to disagree here. It does bring value to a population of developers (me included) for whom that style of programming adds a lot of readability. It's part of style guides for a reason.</div></div></div></blockquote><div>… and it worked well enough, even with only three access levels. Is it really that beneficial to have properties that are only visible to certain extensions in a given file?</div><div>If I had a type that</div><div>a) implements some protocols (or has some other motivation to be split)</div><div>b) has members that should be hidden, but exposed to a single other type (fileprivate would be just fine without this premise)</div><div>c) has no other members that should be shared with a different alien type (that would force us to expose those parts to a type that should have no access)</div><div>d) has elements that are so fragile that they should be protected from any other type (SE-0169)</div><div>e) at the same time, it has to be fine that those fragile members of a nontrivial type can be accessed from all of its extensions that are located in the same file</div><div><br class=""></div><div>SE-0169 would be the perfect answer to such a scenario, but I don't think I will encounter such types often:</div><div>As soon as one requirement isn't fulfilled, the whole purpose of those complicated modifiers is defeated, because our type leaks data that should be contained securely.</div><div>The construct of fileprivate and private with different meanings offers no fundamental benefit over internal — it just delays the issues it wants to solve a tiny bit.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="">— It diminishes the need for fileprivate without making it redundant</div><div class="">It would be nice to get rid of an access level, but having four common ones and fileprivate as an exotic outlier doesn't feel right for me.</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Doesn't the argument of progressive disclosure sway you here? open is already an outlier that only library authors will play with, and that's a good thing. It reduces the number of access level truly useful on a day to day basis, while leaving the others for more narrow purposes.</div></div></div></blockquote></div>I would definitely prefer a set of easy to understand access levels over splitting modifiers in two groups, with one set reserved for "experts".<div class="">Access levels are a very basic concept, and imho they shouldn't need long explanations.</div><div class=""><br class=""></div></body></html>