<div>For all thous who expresses thoughts like "the proposal is too much of a complexity": first of all - I like the open approach of it. It's easily extensible. After that - it gives one the flexibility. For the newbies there are shortcut aliases if they don't want (can't) dig deeper at the moment.</div><div><br></div><div>I think it's a good way to go, because we (the community) still haven't figured out what we want to have at the end of the day. I mean we are all talking about which keywords to use, but the ideology is not nailed down yet... This way we can at least have a consistent model, easily stretchable in the future releases (I hope one day we will come up with something that we would like to put in stone). Until then - I choose flexibility.</div><div><br><div class="gmail_quote"><div>On Sun, 5 Mar 2017 at 11:59 Adrian Zubarev 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 style="word-wrap:break-word" class="gmail_msg"><div class="m_-8410226225165635329bloop_markdown gmail_msg"><p class="gmail_msg">IIRC we might want to introduce enum subtypes in the future right? In previous discussions an enum, that can be subtyped outside your own module was written as <code class="gmail_msg">open enum</code>. I also remember that Brent said enum sub typing should remove cases from your parent enum. So what exactly might happen with <code class="gmail_msg">closed enum</code> after this proposal? Will it become <code class="gmail_msg">open closed enum</code>? That seems really odd.</p>
<p class="gmail_msg">In your proposal you’re saying that the model can be enhanced on that part. How exactly would you imagine this to look like? Bikeshedding is enough for me. <code class="gmail_msg">open(exhaustiveSwitch)</code>, then why would be need <code class="gmail_msg">closed</code> at all if we could write <code class="gmail_msg">public(exhaustiveSwitch)</code> to be consistent on that?</p>
<p class="gmail_msg">I’m simply trying to understand the direction it goes. Thank you for clarification on that. ;)</p>
<p class="gmail_msg"></p></div><div class="m_-8410226225165635329bloop_original_html gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="m_-8410226225165635329bloop_original_html gmail_msg"><div id="m_-8410226225165635329bloop_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_-8410226225165635329bloop_sign_1488707188272037120" class="m_-8410226225165635329bloop_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> <br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="m_-8410226225165635329bloop_original_html gmail_msg"><p class="m_-8410226225165635329airmail_on gmail_msg">Am 4. März 2017 um 20:10:56, Matthew Johnson 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_-8410226225165635329clean_bq gmail_msg"><span class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Sent from my iPad<br class="gmail_msg"><br class="gmail_msg">> On Mar 4, 2017, at 10:09 AM, Rien <Rien@Balancingrock.nl> wrote:<br class="gmail_msg">> <br class="gmail_msg">> <br class="gmail_msg">>> On 04 Mar 2017, at 16:01, Matthew Johnson 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">>> I have updated this proposal with a few more refinements based on yesterday’s discussion. You can find the final proposal on Github:<br class="gmail_msg">>> <br class="gmail_msg">>> <a href="https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilities/proposals/NNNN-scope-bounded-capabilities.md" class="gmail_msg" target="_blank">https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilities/proposals/NNNN-scope-bounded-capabilities.md</a>.<br class="gmail_msg">>> <br class="gmail_msg">>> Matthew<br class="gmail_msg">>> <br class="gmail_msg">>>> On Mar 2, 2017, at 1:58 PM, Matthew Johnson 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">>>> ...<br class="gmail_msg">>>> The rules which make up the essential complexity in Swift's access control system are:<br class="gmail_msg">>>> <br class="gmail_msg">>>> • The default scope for all capabilites a declaration offers is module-wide (or submodule-wide in the future).<br class="gmail_msg">>>> • The scope of a capability may be modified by an explicit access modifier.<br class="gmail_msg">>>> • The scope of an additional capability is implicitly bounded by the scope of the basic capability.<br class="gmail_msg">>>> • The scope of an additional capability may not be explicitly specified as greater than that of the basic capability.<br class="gmail_msg">>>> • If no scope is explicitly provided for the basic capability and an additional capability is specified to be available outside the (sub)module the basic capability is also given the same availability.<br class="gmail_msg">>>> • The scope of a declaration (including all capabilities) may be bounded by the declaration of ancestor.<br class="gmail_msg">> <br class="gmail_msg">> Do you mean: IS bounded by?<br class="gmail_msg"><br class="gmail_msg">No, not necessarily. If the declaration is bounded to the module and all ancestors are public the ancestors don't bound really bound it. I suppose you could say the ancestor still provides a bound that is just never reached. I'm that sense, it depends on how you want to look at it. :)<br class="gmail_msg"><br class="gmail_msg">> <br class="gmail_msg">> <br class="gmail_msg">>>> • The scope of a declaration may not be greater than the scope of the capabilities necessary to use that declaration: if you can't see a parameter type you can't call the function.<br class="gmail_msg">>>> Most of these rules already exist in Swift's access control system. There is one change and one addition:<br class="gmail_msg">> <br class="gmail_msg">> Overall I think the draft is pretty solid.<br class="gmail_msg">> Imo this would give Swift the best available access control system I know of ;-)<br class="gmail_msg">> Thanks for your work on this!<br class="gmail_msg"><br class="gmail_msg">I'm glad to hear you like it! Thanks! I'm hoping the core team is willing to review it for Swift 4 and feedback continues to be positive. It feels like something that should be done in Swift 4 if we're going to do it.<br class="gmail_msg"><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/Balancingrock" class="gmail_msg" target="_blank">http://github.com/Balancingrock</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">> <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>_______________________________________________<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></div>