<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Mar 5, 2017, at 3:59 AM, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>> wrote:<br><br></div><blockquote type="cite"><div><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style><div class="bloop_markdown"><p>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>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>closed enum</code> after this proposal? Will it become <code>open closed enum</code>? That seems really odd.</p></div></div></blockquote><div>No. The semantics of open and closed enums are mutually exclusive. The model of this proposal could be updated to reflect mutually exclusive capabilities or that could be implemented as a higher-level rule.</div><div><br></div><br><blockquote type="cite"><div><div class="bloop_markdown">
<p>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>open(exhaustiveSwitch)</code>, then why would be need <code>closed</code> at all if we could write <code>public(exhaustiveSwitch)</code> to be consistent on that?</p></div></div></blockquote><div>We wouldn't need it. It would be an alias just like open is an alias for public(inherit). This would give it equal syntactic weight as resilient enums for the same reason we decided open classes should have equal syntactic weight to public classes. If we decided that isn't important we could do without it.</div><br><blockquote type="cite"><div><div class="bloop_markdown">
<p>I’m simply trying to understand the direction it goes. Thank you for clarification on that. ;)</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1488707188272037120" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 4. März 2017 um 20:10:56, Matthew Johnson via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div><br><br>Sent from my iPad<br><br>> On Mar 4, 2017, at 10:09 AM, Rien <<a href="mailto:Rien@Balancingrock.nl">Rien@Balancingrock.nl</a>> wrote:<br>> <br>> <br>>> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>>> <br>>> I have updated this proposal with a few more refinements based on yesterday’s discussion. You can find the final proposal on Github:<br>>> <br>>> <a href="https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilities/proposals/NNNN-scope-bounded-capabilities.md">https://github.com/anandabits/swift-evolution/blob/scope-bounded-capabilities/proposals/NNNN-scope-bounded-capabilities.md</a>.<br>>> <br>>> Matthew<br>>> <br>>>> On Mar 2, 2017, at 1:58 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>>>> <br>>>> ...<br>>>> The rules which make up the essential complexity in Swift's access control system are:<br>>>> <br>>>> • The default scope for all capabilites a declaration offers is module-wide (or submodule-wide in the future).<br>>>> • The scope of a capability may be modified by an explicit access modifier.<br>>>> • The scope of an additional capability is implicitly bounded by the scope of the basic capability.<br>>>> • The scope of an additional capability may not be explicitly specified as greater than that of the basic capability.<br>>>> • 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>>>> • The scope of a declaration (including all capabilities) may be bounded by the declaration of ancestor.<br>> <br>> Do you mean: IS bounded by?<br><br>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><br>> <br>> <br>>>> • 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>>>> Most of these rules already exist in Swift's access control system. There is one change and one addition:<br>> <br>> Overall I think the draft is pretty solid.<br>> Imo this would give Swift the best available access control system I know of ;-)<br>> Thanks for your work on this!<br><br>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><br>> <br>> Regards,<br>> Rien<br>> <br>> Site: <a href="http://balancingrock.nl">http://balancingrock.nl</a><br>> Blog: <a href="http://swiftrien.blogspot.com">http://swiftrien.blogspot.com</a><br>> Github: <a href="http://github.com/Balancingrock">http://github.com/Balancingrock</a><br>> Project: <a href="http://swiftfire.nl">http://swiftfire.nl</a><br>> <br>> <br>> <br>> <br>> <br><br>_______________________________________________<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">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></div></blockquote></body></html>