<div dir="ltr">The beauty of Swift 2's access modifiers was that they were based around files and modules, explicitly rejecting types and scopes as units for determining visibility. It seems at base there's a group of people who reject that decision altogether. Hence, new `private`, proposals around `protected`, `friend`, `hidden`, `extensible`, etc.<div><br></div><div>The point of the other thread was that a sizable proportion of people are finding the old system to be elegant and a suitable basis for future enhancements such as submodules. Here, there's another proportion of people who want to dismantle the old design completely. This was pitched already during the Swift 3 evolution process, repeatedly.</div><div><br></div><div>At some point, we've got to stop relitigating this design. It's untenable to have something as foundational as access control change with every version of Swift.</div><div><br></div><div>My two cents are that supporting all the shades of private is completely a non-goal. I've yet to be convinced that more access modifiers will improve anyone's code sufficiently to justify any more turmoil in the language. The Swift 2 way took a very pragmatic approach. When can I access this member? If private: when I have the source code already open; if internal: when I have the source code available to open; if public: whenever. It takes the opinionated (but IMO correct) view that it's not particularly useful for the compiler to hide something from you that you can plainly see and touch.<div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 5:04 PM, Joanna Carter via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What still strikes me as odd is that we now seem to have a plethora of visibilities, some of which do not provide for a given context, some of which seem to be looking for a context to justify their existence.<br>
<br>
Whatever it is called, I find the idea of a file scope visibility somewhat bizarre and at odds with the principle of standard OO class encapsulation.<br>
<br>
The two main reasons I can see for the perceived need for fileprivate are :<br>
<br>
1. being able to separate out "sections" of a class into various extensions<br>
<br>
2. giving global junkies the ability to write all their code in one unit<br>
<br>
Surely, there are members of a type that the writer wants to remain private, even if an extension were declared in the same file. Fine, we have private for that and, even if the writer declares members to be fileprivate, there is no way that any extension declared outside of the file can see those members.<br>
<br>
Now, I have a problem with that. If I want to access non-public members when I extend a type, either I declare those extensions in the same unit and declare those members as fileprivate, or if I want to declare those extensions in another file, I have to move up to the next suitable scope, which is internal.<br>
<br>
But internal is too "open" because it allows, not only my chosen extensions to see those members but, also, any other code in the entire module.<br>
<br>
Having made use of the "friend" concept in C++, this "all or next to nothing" approach to visibility seems to leave me in much the same place as Objective-C, where I could only have private or public, unless I did some tricky stuff with class extensions, something which really didn't look that pretty.<br>
<br>
There are some parts of a type that I would want to remain really, really private to the type, not even visible to an extension.<br>
<br>
There are other parts of a type that I would want to be private to that type but also visible in, but only in, extensions explicitly written against that type.<br>
<br>
Which is why I am suggesting the "extensible" scope : private to the declaring type but also and only visible within any extension to that type.<br>
<br>
Here follows a highly contrived example :<br>
<br>
// Person.swift<br>
public struct Person<br>
{<br>
public var name: String<br>
<br>
public extensible(set) var dateOfBirth: Date<br>
<br>
public var age: Int<br>
{<br>
// return calculated age as of today<br>
}<br>
<br>
init(name: String, dateOfBirth: Date)<br>
{<br>
<a href="http://self.name" rel="noreferrer" target="_blank">self.name</a> = name<br>
<br>
self.dateOfBirth = dateOfBirth // accessible as if it were private<br>
}<br>
<br>
// Registrar.swift<br>
extension Person<br>
{<br>
func correct(dateOfBirth: Date)<br>
{<br>
self.dateOfBirth = …<br>
}<br>
}<br>
<br>
// Test.swift<br>
{<br>
let person = Person()<br>
<br>
person.dateOfBirth = … // compilation error, not visible<br>
}<br>
<br>
IMHO, this then removes one use case for fileprivate in that it allows privileged visibility to private members of a type in extensions, both in the same file and in any other file. But, it also ensures that not other code is allowed access, whether that be in non-extension code in the same file or other non-extension code anywhere else.<br>
<br>
As for case 2. for fileprivate, if a developer wants to put all sorts of globals and other code in one file, then I doubt if they are even going to bother to use fileprivate, especially when they get internal visibility with less typing ;)<br>
<br>
Now, if someone could help me prepare this as a proposal…<br>
<br>
--<br>
Joanna Carter<br>
Carter Consulting<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div></div></div>