<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 class="">I think you hit the nail on the head in that the main issue is that our access control is mixing together several concepts (file-based, type-based, module-based, “open”).</div><div class=""><br class=""></div>I don’t think anyone is actually reading the proposal though. Hidden is file based (not type based). It provides the functionality of protected, but using swift’s file based approach. The reason ‘fileprivate’ goes away is not because it isn’t possible, but because it is essentially redundant (with the shorter keyword of ‘hidden’).<div class=""><br class=""></div><div class="">The big difference is that you can put extensions in separate files within the module (while still expressing intent). Which based on your assertion that "it's not particularly useful for the compiler to hide something from you that you can plainly see and touch” is a good thing.</div><div class=""><br class=""></div><div class="">Also note that my proposal is completely compatible with either the Swift 2 or Swift 3 version of private. It does need one of them to stay, but either would work fine. As you say, having several shades of private is not helpful. </div><div class=""><br class=""></div><div class="">Without something like this, we are going to continue to see a proliferation of new levels/proposals (e.g. friend & protected), each with associated bookkeeping/boilerplate. The idea is to head that off and provide a single concept with enough flexibility to avoid that while still using Swift’s file based approach.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><div class=""><br class=""></div><div class=""><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 13, 2017, at 3:38 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Feb 13, 2017 at 5:04 PM, Joanna Carter 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">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 class="">
<br class="">
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 class="">
<br class="">
The two main reasons I can see for the perceived need for fileprivate are :<br class="">
<br class="">
1. being able to separate out "sections" of a class into various extensions<br class="">
<br class="">
2. giving global junkies the ability to write all their code in one unit<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
Here follows a highly contrived example :<br class="">
<br class="">
// Person.swift<br class="">
public struct Person<br class="">
{<br class="">
public var name: String<br class="">
<br class="">
public extensible(set) var dateOfBirth: Date<br class="">
<br class="">
public var age: Int<br class="">
{<br class="">
// return calculated age as of today<br class="">
}<br class="">
<br class="">
init(name: String, dateOfBirth: Date)<br class="">
{<br class="">
<a href="http://self.name/" rel="noreferrer" target="_blank" class="">self.name</a> = name<br class="">
<br class="">
self.dateOfBirth = dateOfBirth // accessible as if it were private<br class="">
}<br class="">
<br class="">
// Registrar.swift<br class="">
extension Person<br class="">
{<br class="">
func correct(dateOfBirth: Date)<br class="">
{<br class="">
self.dateOfBirth = …<br class="">
}<br class="">
}<br class="">
<br class="">
// Test.swift<br class="">
{<br class="">
let person = Person()<br class="">
<br class="">
person.dateOfBirth = … // compilation error, not visible<br class="">
}<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
Now, if someone could help me prepare this as a proposal…<br class="">
<br class="">
--<br class="">
Joanna Carter<br class="">
Carter Consulting<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
______________________________<wbr 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/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></div></body></html>