<div dir="ltr"><div>It seems to be the opposite, these example work in a playground:<br></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(187,44,162)">let<span style="color:rgb(0,0,0)"> </span>public<span style="color:rgb(0,0,0)">: </span><span style="color:rgb(112,61,170)">Int</span><span style="color:rgb(0,0,0)"> = </span><span style="color:rgb(39,42,216)">123</span></p></div><div><font face="monospace, monospace"><br></font></div></blockquote><div><p style="margin:0px 0px 0px 12px;font-size:11px;line-height:normal;font-family:Menlo">error: keyword &#39;public&#39; cannot be used as an identifier</p><p style="margin:0px 0px 0px 12px;font-size:11px;line-height:normal;font-family:Menlo"><br></p>However:</div><font face="Menlo"><span style="font-size:11px"><div><br></div></span></font><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(187,44,162)">struct<span style="color:rgb(0,0,0)"> Test {</span></p></div><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(187,44,162)"><span style="color:rgb(0,0,0)">    </span>private(set)<span style="color:rgb(0,0,0)"> </span>var<span style="color:rgb(0,0,0)"> set: </span><span style="color:rgb(112,61,170)">Int</span></p></div><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">}</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><br></p></div></blockquote><span style="font-family:Menlo;font-size:11px">no errors</span><br><div>

<font face="Menlo"><span style="font-size:11px"><br></span></font></div>I think that `<font face="monospace, monospace">module</font>` and `<font face="monospace, monospace">file</font>` without further context may be confusing. I also think that `<font face="monospace, monospace">class</font>` that I had is probably confusing.<div><br></div><div>I don&#39;t see the additional verbosity as a problem, I think the more frequently used ones are probably fine.</div><div><br></div><div>I&#39;m happy for them all to be keywords, the original proposal had some good suggestions there, I just think what I&#39;ve suggested is a bit nicer.<div><br></div><div>I think that what I&#39;m suggesting would increase safety and granularity, with only one new case you didn&#39;t have, and it would actually reduce the number of keywords.</div><div><div><div><font face="Menlo"><span style="font-size:11px"><br></span></font></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 1:51 PM, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 25, 2016, at 8:37 PM, Andrew Bennett &lt;<a href="mailto:cacoyi@gmail.com" target="_blank">cacoyi@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr"><div>I like file scoped private, it&#39;s way better than C++&#39;s `friend`. I also often feel that it&#39;s unsafe when I&#39;ve mentally scoped implementation details to a class or extension, but the implementations are in the same file.</div><div><br></div><div>I would support something like this:<br></div><div><div>    * `<span style="font-family:monospace,monospace">private</span><font face="monospace, monospace">(module)</font>` alternatively `<font face="monospace, monospace">internal</font>`, the default.<br></div><div>    * `<font face="monospace, monospace">private</font>` alternatively `<span style="font-family:monospace,monospace">private</span><font face="monospace, monospace">(file)</font>`</div><div>    * `<span style="font-family:monospace,monospace">private</span><font face="monospace, monospace">(class)</font>`</div><div>    * `<span style="font-family:monospace,monospace">private</span><font face="monospace, monospace">(extension)</font>`</div><div>    * `<font face="monospace, monospace">public</font>`</div></div></div></div></blockquote><div><br></div></span><div>I like the basic breakdown of functionality here, but why overload private with so many variations?  This is more verbose than necessary.  I think we can get away with being more clear and concise (access modifiers are decl modifiers, not keywords so they don’t steal identifiers, IIUC).</div><div><br></div><div>Why not this:</div><div><br></div><div><div dir="ltr"><div><div>    * `<font face="monospace, monospace">public</font>`</div></div></div></div><div>    * `<font face="monospace, monospace">module</font>`, the default (currently `internal`).<br>    * `<font face="monospace, monospace">file</font>` (currently `private`)<br>    * `<span style="font-family:monospace,monospace">private</span>` (no current equivalent: containing scope whether class, struct, enum, extension, etc)</div><div><div class="h5"><br><blockquote type="cite"><div><div dir="ltr"><div><div><br></div><div>Perhaps this could let us deprecate/remove the keyword `<font face="monospace, monospace">internal</font>`, I&#39;m not sure of many circumstances when you&#39;d actually need to write it.</div><div><br></div><div>I also think that `<span style="font-family:monospace,monospace">private</span><font face="monospace, monospace">(module)</font>` is also more intuitively understood than `<span style="font-family:monospace,monospace">internal</span>`.</div><div><br></div><div><b>My reasoning:</b></div><div><br></div><div><div>This seems to come down to:</div><div><ul><li>It lowers the cognitive load if you can put related concepts in the same file.<br></li><li>It lowers the cognitive load if you can reduce the number of things a class needs to understand.</li><li>People like the current system, its simple and it works for them.</li></ul></div></div><div>&quot;Everyone knows that debugging is twice as hard as writing a program in the first place. So if you&#39;re as clever as you can be when you write it, how will you ever debug it?&quot; - The Elements of Programming Style<div><br></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 26, 2016 at 12:46 PM, Matthew Johnson via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
&gt; On Jan 25, 2016, at 5:47 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; on Mon Jan 25 2016, Ilya Belenkiy &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;&gt; Why should the compiler enforce this? That’s my design decision.<br>
&gt;&gt;<br>
&gt;&gt; It would enforce whatever design decision you make.<br>
&gt;&gt;<br>
&gt;&gt;&gt; For the same reason the compiler does not enforce where I have to<br>
&gt;&gt;&gt; put „private“ (it can make suggestions like many IDEs do and offer<br>
&gt;&gt;&gt; fix-its, like „this method can be made private as it is not used<br>
&gt;&gt;&gt; outside the class“ or „this class can be put into its own file as<br>
&gt;&gt;&gt; its private methods are not used by other components in this file“.<br>
&gt;&gt;<br>
&gt;&gt; But once you do put it, it enforces it, and that’s the whole point of having access control.<br>
&gt;&gt;<br>
&gt;&gt;&gt; No, there is a clear difference: making the type name part of the<br>
&gt;&gt;&gt; variable name enforces no compiler checks whereas putting something<br>
&gt;&gt;&gt; into different files does.<br>
&gt;&gt;<br>
&gt;&gt; Similarly, putting all of the source code in the same file is<br>
&gt;&gt; equivalent to no checks.<br>
&gt;<br>
&gt; The place where I&#39;m most concerned about this is in playgrounds.  If<br>
&gt; we&#39;re going to use them to teach programming, it should be possible to<br>
&gt; demonstrate encapsulation there.<br>
&gt;<br>
<br>
</span>Using playgrounds for teaching is a great example of a use case for this.  Thanks for mentioning it!<br>
<br>
I also think the fact that “surrounding scope” is actually the most frequent use of `private` members (in code I have surveyed) indicates that it is a very reasonable feature request.  Allowing us to declare the actual intent aids readability and clarity.<br>
<br>
-Matthew<br>
<div><div><br>
&gt; --<br>
&gt; -Dave<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div>