<html><head><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></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>–1 </p>
<p>I won’t even try to be constructive on this one. It simply makes me tired of all this access modifier mess. <code>open</code>, <code>closed</code>, <code>public</code>, <code>internal</code>, now <code>hidden</code>, <code>fileprivate</code>, <code>directoryprivate</code>, <code>moduleprivate</code>, <code>private</code>, I might even forget some of the proposed access modifiers.</p>
<p>Instead of adding new stuff that explodes the complexity we should put our energy and fix existing issues, like the inconsistent <code>open</code> for example.</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_1486995106638309120" 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 13. Februar 2017 um 15:06:45, Jonathan Hull 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>I wanted to propose a second simplification to the access system which would have several benefits:<br><br> • It would remove ‘fileprivate’<br> • It would allow extensions to be in their own files<br> • It would serve the needs of ‘protected’ without the complications involved in that<br> • It would serve some of the needs of submodules (but also work together with them really nicely when we have both)<br> • It would allow protocols to have something similar to private methods, which are not exposed to callers of the protocol, but still required for conformance<br><br><br>My proposal is to add a ‘hidden’ access modifier which would act as a separate AXIS as opposed to a new level. Thus, it could be combined with any of the other modifiers (e.g. 'public hidden var’). The ‘fileprivate’ level would be removed.<br><br>Anything which is marked hidden is not visible outside of the file it is defined in. That visibility can be explicitly restored on a per file basis (but only within the defined access level). Take a look at the following:<br><br> //File: MyStruct.swift<br><br> struct MyStruct {<br> var a:Int<br> hidden var b:Int<br> }<br><br> extension MyStruct {<br> var biggest:Int {return max(a,b)} //We can still see ‘b’ because it is only hidden outside the file<br> }<br><br>Here we see that ‘b’ behaves very similarly to the way fileprivate works now. ‘b’ is technically still internal, but it is hidden and thus can’t be seen outside the file. The difference is that instead of being forced to add all of our extensions in the same file, we can organize them however we prefer.<br><br> //In another file<br> import hidden MyStruct //This exposes all ‘hidden’ items from the file MyStruct to this file<br><br> extension MyStruct {<br> var c:Int {return a + b} //We can see ‘b’ because of the ‘import hidden’ statement<br> }<br><br><br>Notice how the intent has been shown here. ‘b’ is marked ‘internal’, which means we know that no one can see ‘b’ outside of the module. In addition ‘b’ is marked ‘hidden’, which means that the author is saying that this should only really be accessed from extensions, subclasses, or types which would be called friends in other languages. The actual guarantee is still ‘internal’, but a caller does have to explicitly request the access by typing ‘import hidden’, which will stop accidental/casual misuse. (If/when we get submodules, then we can make tighter guarantees)<br><br>This also allows a class to “hide the ejection seat levers” from its callers, while still allowing access for subclasses and extensions (i.e. it does most of what ‘protected’ would do, but with swift’s simpler file-based access model)<br><br>The same is true of protocols. There are often methods I have to include on protocols which are needed by the default implementations, but NEVER meant to be called directly by callers of the protocol. If vars/methods of a protocol are marked hidden, then they would be hidden from callers of the protocol outside the file. They are still required for conformance, however*. <br><br> protocol MyProtocol {<br> var a:Int<br> hidden var b:Int //Conformers still need to provide this, but callers can’t see it<br> }<br><br> extension MyProtocol {<br> func doSomethingBasedOnB() {<br> //The extension can see b in the same file, but callers in other files won’t have access to ‘b’ directly<br> }<br> }<br><br>I think all of this works really well with Swift’s goal of progressive disclosure. Users of protocols/classes/etc… are not exposed to the internals necessary for extension (e.g. it won’t come up in autocomplete) until they actually need to conform/subclass/extend. Users won’t even need to learn about ‘hidden' until they are trying to extend a type which uses it (in a way which requires access to those internals), or they are writing their own framework. It has a simple and consistent meaning based on Swift’s original file-based access, but allows power/flexibility (without too much bookkeeping/boilerplate) where needed.<br><br>Thanks,<br>Jon<br><br><br>* One detail needed to make things useful for protocols, is that both hidden and non-hidden vars/methods on the conforming type should count towards conformance of hidden vars/methods on the protocol. Basically, marking something as ‘hidden’ on a protocol means it isn’t seen by the caller (only conformers/extensions). It makes sense to allow the conformer not to expose that either, unless desired. It would technically work fine without this allowance, but it ‘feels right’ and people would ask for it quickly...<br><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>