<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>-1 looks like a kludgy hack. </div><div id="AppleMailSignature">It will force people to have to scroll back to the declaration of a group (with no assistance to find where it is) in order to ascertain the visibility of a given method, while pushing code further to the right for every single method. Couple that with the zealous following of the 80c rules and that makes for a less than stellar coding experience... all in the name of not have to type a modifier.<br><div>Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div><br>On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</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>Dear Swift community, as most of you may know we’ve been discussing the future of extintials and diverse design ideas. The result for Swift 3 is a proposal which makes the first step by replacing <code>procotol<A, B></code> with a new shorthand syntax <code>A & B</code>.</p>
<p>The reason I’m posting this proposal so early is to get some feedback about this idea in general. If the feedback is positive, I also would like some of you to consider the removal of the access modifier from extensions. By that I don’t mean to remove it completely. My honest opinion is that extensions should have exactly the same access control like classes, enums and structs. </p>
<p>One take the access control from protocols and mix it with the access control of classes (etc.) and the result is the access control for extensions. I just can’t agree with the fact of laziness of typing out access modifier on extension members some of you might have. </p>
<ul>
<li><p>The current access control on extensions disallow us to use access modifier when we involve protocol conformances. </p></li>
<li><p>Default implementations have three ways of declaring public visibility:</p>
<pre><code class="swift">extension SomeProtocol {
public func someMember() {}
}
public extension SomeProtocol {
func someMember() {}
}
public extension SomeProtocol {
public func someMember() {}
}
</code></pre>
<p>If it was the access control mechanism for classes (etc.) there would be only a single correct way to achieve this:</p>
<pre><code class="swift">public class SomeClass {
public func someMember() {}
}
</code></pre></li>
</ul>
<p>Feel free to join the conversation about removing the current behavior from extensions for Swift 3. Here is the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022511.html">>>link<<</a> to the last post. (I still have to rewrite a few things to reflect my thoughts from the conversation.)</p>
<hr>
<p>I’d like to introduce a new scoped but typeless mechanism to Swift (which might be added after Swift 3 drops). I gave it a clean name <code>group</code> to showcase what it will be used for. You can read my formatted draft <a href="https://gist.github.com/DevAndArtist/c74f706febf93452999881335f6ca1f9">>>here<<</a>.</p>
<p>These were the basic ideas I had. I’ve already seen a few threads where some people were asking for a way organizing variables into groups by an access modifier. So here it is, but a <code>group</code> can solve other problems too. We could finally stop abusing enums and also create <em>access labels</em> for a clear and swifty code design.</p>
<p>The idea of groups is based on the access control of protocols. It would be great if this mechanism could have its own scope, which then could be used almost anywhere.</p>
<hr>
<h2 id="detaileddesign">Detailed design</h2>
<ul>
<li><p>A <code>group</code> is typeless, and should be used for organization purposes.</p>
<ol>
<li><p>Organizing members by an <em>access modifier</em>.</p></li>
<li><p>Providing an <em>access label</em> to type members (CamelCase).</p></li>
<li><p>Providing <em>namespacing</em> for API design (UpperCamelCase).</p>
<pre><code class="swift">public group Reference {
/* implicitly public */ class String { ... }
/* implicitly public */ class Char { ... }
}
</code></pre>
<p>Possible usage:</p>
<pre><code class="swift">let instance = Reference.String()
</code></pre></li>
</ol></li>
<li><p>A <code>group</code> can be used inside any scope or at file level.</p></li>
<li><p>A <code>group</code> has one or no label at all:</p>
<ul>
<li><p>A <code>group</code> without a label has always an explicit <em>access modifier</em>:</p>
<pre><code class="swift">public struct A {
public group {
var a: Int { return self._a }
var aTimesTen: Int { return self.a * 10 }
}
internal group {
var _a: Int = 10
var _b: Int = 42
}
}
</code></pre></li>
<li><p>A <code>group</code> with a label has an <em>optional</em> access modifier:</p>
<ol>
<li>Labeled groups without an access modifier are automatically <code>internal</code>.</li>
<li>Group members have the same access modifier as the group itself (like access modifier on protocols).</li>
<li>Nested groups inherit the access modifier from its root <code>group</code>.</li>
<li>Labeled groups cannot be stored in any manner.</li>
</ol>
<pre><code class="swift">public class UIScrollView : ... {
public group {
/* implicitly public */ group content {
/* implicitly public */ var offset: CGPoint
/* implicitly public */ var size: CGSize
/* implicitly public */ var inset: UIEdgeInsets
}
/* implicitly public */ var someCoolPublicInteger: Int
}
...
}
</code></pre>
<p>Possible usage:</p>
<pre><code class="diff">- scrollViewInstance.contentOffset
+ scrollViewInstance.content.offset
</code></pre></li>
</ul></li>
<li><p>It should be possible to create multiple groups with the same/different access modfier and the same acess label:</p>
<pre><code class="swift">public struct B {
public group labelName {
var someVarName: Int
}
public group labelName {
var someOtherVarName: String
}
internal group labelName {
var _internalVarName: Double
}
}
</code></pre></li>
<li><p>It should be possible to extend existing labeled groups.</p>
<pre><code class="swift">public struct C {
public group labelName {
var someVarName: Int
}
}
public extension C {
public group labelName {
var computedProperty: Int { ... }
}
}
</code></pre></li>
<li><p>Attributes aplied to a <code>group</code> will automatically be aplied to all members.</p>
<pre><code class="swift">public class D {
public static group {
// public static var
var something: Int = 42
// public static func
func foo() { ... }
}
}
</code></pre></li>
</ul>
<h3 id="grammar">Grammar</h3>
<p><em>declaration</em> → <em>group-declaration</em></p>
<p><em>group-declaration</em> → <em>attributes</em><sub>opt</sub> <em>access-level-modifier</em> <strong>group</strong> <em>group-body</em> </p>
<p><em>group-declaration</em> → <em>attributes</em><sub>opt</sub> <em>access-level-modifier</em><sub>opt</sub> <strong>group</strong> <em>group-name</em> <em>group-body</em> </p>
<p><em>group-name</em> → <em>identifier</em></p>
<p><em>group-body</em> → <strong>{</strong> <em>declarations</em> <strong>}</strong></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_1467206407803821056" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div></div><div class="bloop_markdown"><p></p></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>