<div style="white-space:pre-wrap">Folks, it really gets intense (and I really like it, while not being satisfied with current system) and looks like reconsidering from scratch. To make the further communication productive let's first bring the bigger picture into context.<br><br>Let's bring some history first.<br><br>Initially Swift adapted the model from Obj-C. The main argument from Apple was compatibility and "it's not bad, just different; try to adapt". There was a blog article about it on Apple's site. Sorry don't have a link.<br><br>Well, anyways, with Swift 3 it no longer is as simple as it is in Obj-C. New modifiers were introduced by request. I feel it's good and means everybody agrees Obj-C modifiers aren't sufficient for Swift. What I mean, initial arguments should apply no more and I hope Apple will not be too rigid with current status.<br><br>What I mean, though, the new introductions of access modifiers feel quite some "patchy".<br><br>Let's bring the discussion to why we need access control into the first place. As for me it is:<br>1. Possibility to provide a clean, safe API from middleware (frameworks)<br>2. While working as a team on a single project, restrict others from misuse of your APIs.<br><br>The other breakdown is what types of APIs we might have:<br>1. Simple "allocate and use"<br>2. APIs that require some kind of inheritance, protocol implementations, overriding, etc.<br><br>I'm not pretending these lists are complete, so please feel free to add your use cases.<br><br>As a framework developer I personally suffer quite some from inability to have protected (or any alternative) methods in protocols. It comes from absence of multiple inheritance (which I'm completely fine with) and inability to fully replace it with protocols.<br><br>One of the simple examples would be: you need an API that requires overriding? Make it accessible for ancestors only (even in protocols). Despite the argument "ancestors can open it to public" (there are a lot of dangerous things to do) it makes the API much more clean and hides implementation complexity. Otherwise you just have to explain it in the doc "please don't call this method, it's an internal" which feels wrong.<br><br>So, what I suggest:<br>1. Keep public/open which is cool<br>2. Add protected which should solve the inheritance issue<br>3. Add "inner" which is a bit wider than protected and allows to access members from extension<br>4. Keep internal, but make it an "additional marker" which keeps anything from being visible outside of the module. I mean like a member can be at the same time protected and internal<br>5. Apply the very same thing to protocols (I know it's controversial; still I believe the language should be consistent and solid. The same rules should apply everywhere). It will add more flexibility for API devs (keep in mind we don't have other way of multiple inheritance)<br>6. Please add your use cases<br><br>It is not a replacement of proposal with fine grained tunable custom modifiers, but rather a try to rethink from scratch what we need considering we are already far from the initial concept.<br><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 2 Dec 2016 at 13:36 Gonçalo Alvarez Peixoto via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">@Adrian<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I do agree with you when you state "<span style="font-size:12.800000190734863px" class="gmail_msg">But instead of introducing even more access modifiers we probably should fix some of the existing ones". As I mentioned in the proposal, typeprivate level could somehow replace fileprivate which, in my opinion, falls short in promoting good design practices. While I'm sure that's not it's intent, it surely creates conditions for some dodgy patterns to emerge.</span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">Also, would you be so kind to provide an example where typepublic would be useful? Maybe you're thinking of allowing member access to subclasses? Would that fall into a possible "protected" realm?</span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">I agree we should handle protocol access control as well. In fact, I believe protocols in general should be subject of focus if we're to promote a protocol oriented programming environment. I believe there's some aspects within protocol usage which also lack robustness which lead, for instance, to type erasure solutions, which in my opinion feel like some somehow hacky.</span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">Still, I believe there's so much we can add to protocol access control level, one can actually build a proposal out of it (I'd gladly take part of this discussion as well!), otherwise we'd be adding so much more to this proposal's intent than what it's essence demands: a way to access private members on extensions placed on separate files.</span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">@Rien</span></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">"And the funny thing is, we don’t actually _need_ access control levels."</span></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">I tend do disagree. I believe we do profit from access control levels in many many ways. One does profit from clearer and safer API communication. I assume you consider that's vital as well since you do suggest a finer grained list of access control levels.</span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">"I consider it dangerous by default to open up a scope just because another class needs occasional". </span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg">Couldn't agree more! </span><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Best,</div><div class="gmail_msg">Gonçalo</div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.800000190734863px" class="gmail_msg"><br class="gmail_msg"></span></div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">2016-12-02 10:43 GMT+00:00 Adrian Zubarev via swift-evolution <span dir="ltr" class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span>:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="m_-1884133016779901019m_-7243592002236992209bloop_markdown gmail_msg"><p class="gmail_msg">There is some really deep talk going on here again. But instead of introducing even more access modifiers we probably should fix some of the existing ones. </p>
<p class="gmail_msg">Don’t get me wrong, I understand what the authors of the proposal are trying to introduce to the language, but even if such a proposal would be accepted, there will be people who would beg for <code class="gmail_msg">typepublic</code> access modifier.</p>
<p class="gmail_msg">I tried to get some attention from the community after we introduced <code class="gmail_msg">open</code> to the language, because we literally created an inconsistent area for protocols. </p>
<p class="gmail_msg">Now we have <code class="gmail_msg">open</code> vs <code class="gmail_msg">public</code> classes, where <code class="gmail_msg">open</code> means you can subclass your type from module A in module B, and <code class="gmail_msg">public</code> prevents this.</p>
<p class="gmail_msg">What’s up with protocols?</p>
<p class="gmail_msg"><code class="gmail_msg">(protocol) conforming == abstract subtyping (classes)</code></p>
<p class="gmail_msg">Fixing this area would prevent the API user from using protocols which are public but not meant to be used there (at least not to be conformed to), because there was some implementation artifact that prevented the framework author from hiding such a protocol.</p>
<p class="gmail_msg">Something like “hands off from <code class="gmail_msg">_SomeName</code> protocols” could be enforced by the language rather than some convention, which some API users might not even read. </p>
<p class="gmail_msg">That said, some hacks like this should be prevented:</p>
<pre class="gmail_msg"><code class="m_-1884133016779901019m_-7243592002236992209swift gmail_msg">struct A : _ExpressibleByBuiltinIntegerLiteral {
init(_builtinIntegerLiteral value: _MaxBuiltinIntegerType) {}
}
struct B : ExpressibleByIntegerLiteral {
init(integerLiteral value: A) {
print(type(of: value))
}
}
let b: B = 42 // prints "A"
</code></pre>
<p class="gmail_msg">We introduced an exclusive access modifier for classes which is really odd to be honest. We should extend it to protocols as well.</p>
<p class="gmail_msg">In Module A:</p>
<ul class="gmail_msg">
<li class="gmail_msg">open protocol X - can be conformed to from module B</li>
<li class="gmail_msg">public protocol Y - cannot be confronted to from module B, but instead might be used as an interface</li><span class="m_-1884133016779901019HOEnZb gmail_msg"><font color="#888888" class="gmail_msg">
</font></span></ul><span class="m_-1884133016779901019HOEnZb gmail_msg"><font color="#888888" class="gmail_msg">
<p class="gmail_msg"></p></font></span></div><div class="m_-1884133016779901019m_-7243592002236992209bloop_original_html gmail_msg"><span class="m_-1884133016779901019HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><div id="m_-1884133016779901019m_-7243592002236992209bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><br class="gmail_msg"></div> <br class="gmail_msg"> <div id="m_-1884133016779901019m_-7243592002236992209bloop_sign_1480674204626516992" class="m_-1884133016779901019m_-7243592002236992209bloop_sign gmail_msg"><div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg">-- <br class="gmail_msg">Adrian Zubarev<br class="gmail_msg">Sent with Airmail</div></div></font></span><div class="gmail_msg"><div class="m_-1884133016779901019h5 gmail_msg"> <br class="gmail_msg"><p class="m_-1884133016779901019m_-7243592002236992209airmail_on gmail_msg">Am 2. Dezember 2016 um 09:56:49, Rien via swift-evolution (<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="m_-1884133016779901019m_-7243592002236992209clean_bq gmail_msg"><span class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">And the funny thing is, we don’t actually _need_ access control levels.<br class="gmail_msg"><br class="gmail_msg">The only purpose of access control is to enhance security/reliability by imposing restrictions on other programmers (API users).<br class="gmail_msg"><br class="gmail_msg">It seems to me that in almost all discussions the arguments are mostly backwards: i.e. formulated from the perspective of the API users. Maybe because just about all programmers are API users of the OS-API? Anyway…<br class="gmail_msg"><br class="gmail_msg">What I would like to see is a complete overhaul of the access control and rewrite it entirely from the perspective of the API provider.<br class="gmail_msg">I.e. give a more fine grained control to the API writer in the sense that he can specify exactly which other piece of code has access. I consider it dangerous by default to open up a scope just because another class needs occasional access. (i.e. give -for example- module access just because there is 1 other class in the module that needs that access. Inadvertently opening up access to all other classes in that module.)<br class="gmail_msg"><br class="gmail_msg">An access control list could do just that. Perhaps something like:<br class="gmail_msg"><br class="gmail_msg">access(type, MyFriendClass(get))<br class="gmail_msg"><br class="gmail_msg">The above would provide access to the entire type (but not any children) and read-only from MyFriendClass.<br class="gmail_msg"><br class="gmail_msg">A quick -off the cuff- list of access levels:<br class="gmail_msg"><br class="gmail_msg">local: access only to local scope (default)<br class="gmail_msg">type: Only the type in which it is defined (no children)<br class="gmail_msg">child: The type and its children<br class="gmail_msg"><type-name>: Access is granted to the type named<br class="gmail_msg">file: Access is limited to this file only<br class="gmail_msg"><file-name>: Access is granted to the named file<br class="gmail_msg">module: Access is granted to the entire module<br class="gmail_msg"><module-name>: Access is granted to the module with the given name<br class="gmail_msg">public: Access is granted to everybody<br class="gmail_msg"><br class="gmail_msg">Further access specification could be made possible through the use of the dot-notation:<br class="gmail_msg"><br class="gmail_msg"><type-name>.<function-name><br class="gmail_msg"><file-name>.<class-name | function-name><br class="gmail_msg"><module-name>.<class-name>.<function-name><br class="gmail_msg"><br class="gmail_msg">Read/write control through a parameter passing notation:<br class="gmail_msg"><br class="gmail_msg"><type-name>.<function-name>([[get],][set])<br class="gmail_msg"><br class="gmail_msg">Examples:<br class="gmail_msg"><br class="gmail_msg">access(type) var count: Int // entire type can read/write<br class="gmail_msg">access(type(get), type.incrementer) var count: Int // Entire type can read, only the incrementer function has read/write<br class="gmail_msg">access(module, FriendType, public(get)) var count: Int // Entire module can read/write, FriendType can read/write, others can only read<br class="gmail_msg"><br class="gmail_msg">Regards,<br class="gmail_msg">Rien<br class="gmail_msg"><br class="gmail_msg">Site: <a href="http://balancingrock.nl" class="gmail_msg" target="_blank">http://balancingrock.nl</a><br class="gmail_msg">Blog: <a href="http://swiftrien.blogspot.com" class="gmail_msg" target="_blank">http://swiftrien.blogspot.com</a><br class="gmail_msg">Github: <a href="http://github.com/Swiftrien" class="gmail_msg" target="_blank">http://github.com/Swiftrien</a><br class="gmail_msg">Project: <a href="http://swiftfire.nl" class="gmail_msg" target="_blank">http://swiftfire.nl</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">> On 01 Dec 2016, at 21:38, Brandon Knope via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">> <br class="gmail_msg">> Is anyone starting to think the current access control model will become more burdensome over time?<br class="gmail_msg">> <br class="gmail_msg">> People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language. <br class="gmail_msg">> <br class="gmail_msg">> For example, fileprivate and private encourage stuffing a lot of code into one file just to use that access control level. If you want to break this into more manageable chunks you have to make it internal or move it into a new module which is very complicated to do in Xcode (I.e requiring a new target like a framework). <br class="gmail_msg">> <br class="gmail_msg">> This keeps leading me back to having submodules or creating modules on demand. I think that would open up this system to great complexity.<br class="gmail_msg">> <br class="gmail_msg">> Want to keep something private to a specific class but private to anything outside of it? Make it internal to the same "submodule". <br class="gmail_msg">> <br class="gmail_msg">> I think we could keep tacking on things to access control, but I don't think it is really solving everyone's needs. I think a more flexible system would allow people to adapt it to their needs instead of structuring everything around a rigid system that forces you to do it swift's way. <br class="gmail_msg">> <br class="gmail_msg">> On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">> <br class="gmail_msg">>> Hello, everyone!<br class="gmail_msg">>> <br class="gmail_msg">>> I would like to introduce a new proposal to swift evolution, but first I would love to run it by all of you so I get everyone's feedback and enrich it.<br class="gmail_msg">>> <br class="gmail_msg">>> This proposal consists of introducing a new typeprivate access control level which allows for members to be accessed in all extensions of a given type, whether lying within or in another file.<br class="gmail_msg">>> <br class="gmail_msg">>> You'll find the proposal draft in:<br class="gmail_msg">>> <a href="https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md" class="gmail_msg" target="_blank">https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md</a><br class="gmail_msg">>> <br class="gmail_msg">>> Thanks in advance for taking the time to evaluate the proposal.<br class="gmail_msg">>> <br class="gmail_msg">>> Best regards,<br class="gmail_msg">>> Gonçalo<br class="gmail_msg">>> _______________________________________________<br class="gmail_msg">>> swift-evolution mailing list<br class="gmail_msg">>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">> _______________________________________________<br class="gmail_msg">> swift-evolution mailing list<br class="gmail_msg">> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></div></span></blockquote></div></div></div><div class="m_-1884133016779901019m_-7243592002236992209bloop_markdown gmail_msg"><p class="gmail_msg"></p></div></div><br class="gmail_msg">_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>