<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 for me.</p>
<p>IMO the current behavior reduces all that <code>internal</code> noise in large projects, where the author only makes a small part of the API public. Furthermore this will break the implicit initializer on structs and make it implicitly public. Leaving the initializer as <code>internal</code> while everything else is <code>public</code> as a workaround would be inconsistent solution, so that’s a no go. Personally I think that will introduce more noise than the current behavior, because we’ll have to repeat <code>internal</code> all over the place in large projects. So in my eyes this would be a regression.</p>
<p>P.S.: I’m curious what the core team has to say about this.</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_1486991557972224000" 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 10:02:39, 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 would like to propose a change to the default access modifier within an enclosing scope. The default for top level definitions would stay internal, but anything within a scope would by default have the same visibility as it’s enclosing scope.<br><br>The main reason for this is readability/maintainability, and having the intention clearly stand out. It would also reduce a great amount of boilerplate. It also matches the mental model of how scopes normally work regarding inheritance of visibility/properties (which means less to teach newbies).<br><br>Right now if I want to make a type and all of it’s vars/methods public, I have to mark each individual var/method public, which leads to a lot of boilerplate/noise and makes everything harder to read:<br><br> public struct MyStruct {<br> public var a:Int<br> public var b:Int<br> private var c:Int<br> public var d:Int<br> }<br><br>Notice that the private var doesn’t really stand out as such very well. Also, it is exceedingly rare (at least in my own coding style) that I actually want an internal variable unless the type itself is internal, and in those cases, I would like that choice to stand out as deliberate the same way I want ‘private' to stand out. As it stands, I wait until I think I am done modifying a type to mark it public because of the extra noise generated. I also make a point to write ‘internal' for things that I explicitly want to restrict to internal.<br><br>Consider the alternative:<br><br> public struct MyStruct {<br> var a:Int<br> var b:Int<br> private var c:Int<br> var d:Int<br> }<br><br>Now the fact that I have chosen to make ‘c’ private really stands out much better. When revisiting the code in 6 months, the struct is much more “glance-able” (as a friend of mine likes to say).<br><br>Note also the nuance that I didn’t say that those vars were marked public (or had the same modifier), I said that they had the SAME VISIBILITY as the enclosing scope (which in this case happens to be public). This is a concept which is hard to express currently, and IIRC this is what we had to do to make the edge cases of swift 3’s private modifier work properly. <br><br>Basically, it already works this way for ‘private’, ‘fileprivate’, & ‘internal’, just not for ‘public’ or ‘open’… which can be surprising, especially since you don’t discover these differences until you are working across modules. We should just extend that mental model up to include public and open. Migration would just take internal variables of public/open types and mark them explicitly with the word ‘internal'.<br><br>Thanks,<br>Jon<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>