<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 9:22 PM, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" class="">cacoyi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">It seems to be the opposite, these example work in a playground:<br class=""></div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(187, 44, 162);" class="">let<span style="" class=""> </span>public<span style="" class="">: </span><span style="color:rgb(112,61,170)" class="">Int</span><span style="" class=""> = </span><span style="color:rgb(39,42,216)" class="">123</span></div></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div></blockquote><div class=""><div style="margin: 0px 0px 0px 12px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">error: keyword 'public' cannot be used as an identifier</div><div style="margin: 0px 0px 0px 12px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><br class=""></div>However:</div><font face="Menlo" class=""><span style="font-size:11px" class=""><div class=""><br class=""></div></span></font><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(187, 44, 162);" class="">struct<span style="" class=""> Test {</span></div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(187, 44, 162);" class=""><span style="" class=""> </span>private(set)<span style="" class=""> </span>var<span style="" class=""> set: </span><span style="color:rgb(112,61,170)" class="">Int</span></div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">}</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><br class=""></div></div></blockquote><span style="font-family:Menlo;font-size:11px" class="">no errors</span><br class=""></div></div></blockquote><div><br class=""></div><div>You are right. The access modifiers are not available as identifiers while most other decl modifiers are allowed: <a href="https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/doc/uid/TP40014097-CH30-ID410" class="">https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/doc/uid/TP40014097-CH30-ID410</a>. I should have checked before mentioning what I did about decl modifiers.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">
<font face="Menlo" class=""><span style="font-size:11px" class=""><br class=""></span></font></div>I think that `<font face="monospace, monospace" class="">module</font>` and `<font face="monospace, monospace" class="">file</font>` without further context may be confusing. I also think that `<font face="monospace, monospace" class="">class</font>` that I had is probably confusing.</div></div></blockquote><div><br class=""></div>You’re probably right about `module` and `file` having potential for confusion without context. With that in mind, `internal` is probably better than `module` and is what we already have..</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I don't see the additional verbosity as a problem, I think the more frequently used ones are probably fine.</div><div class=""><br class=""></div><div class="">I'm happy for them all to be keywords, the original proposal had some good suggestions there, I just think what I've suggested is a bit nicer.<div class=""><br class=""></div><div class="">I think that what I'm suggesting would increase safety and granularity, with only one new case you didn't have, and it would actually reduce the number of keywords.</div></div></div></div></blockquote><div><br class=""></div>I did cover all of your cases. Making a distinction based on the type of scope (class vs extension) doesn’t seem to be worthwhile. If you really wanted to stick with the private syntax `private(scope)` would make the most sense and would work for any kind of scope.</div><div><br class=""></div><div>However I think that is verbose. I think we have a couple of reasonable options.</div><div><br class=""></div><div>Ilya’s proposal and closest to current state:</div><div>* public, internal, private, local (or scoped)</div><div><br class=""></div><div>Change `private` to be scope-based and come up with something new for file-level visibility:</div><div>* public, internal, ??? file level, private<br class=""><div><br class=""></div><div>My preference depends on what we could come up with for file-level visibility. If it’s better than `local` or `scoped` I would prefer that. If not, I would prefer Ilya’s proposal. In other words, we should choose the option with the best overall clarity.</div><div><br class=""></div><div>-Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""><span style="font-size:11px" class=""><br class=""></span></font></div></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jan 26, 2016 at 1:51 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 8:37 PM, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" target="_blank" class="">cacoyi@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">I like file scoped private, it's way better than C++'s `friend`. I also often feel that it's unsafe when I've mentally scoped implementation details to a class or extension, but the implementations are in the same file.</div><div class=""><br class=""></div><div class="">I would support something like this:<br class=""></div><div class=""><div class=""> * `<span style="font-family:monospace,monospace" class="">private</span><font face="monospace, monospace" class="">(module)</font>` alternatively `<font face="monospace, monospace" class="">internal</font>`, the default.<br class=""></div><div class=""> * `<font face="monospace, monospace" class="">private</font>` alternatively `<span style="font-family:monospace,monospace" class="">private</span><font face="monospace, monospace" class="">(file)</font>`</div><div class=""> * `<span style="font-family:monospace,monospace" class="">private</span><font face="monospace, monospace" class="">(class)</font>`</div><div class=""> * `<span style="font-family:monospace,monospace" class="">private</span><font face="monospace, monospace" class="">(extension)</font>`</div><div class=""> * `<font face="monospace, monospace" class="">public</font>`</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">Why not this:</div><div class=""><br class=""></div><div class=""><div dir="ltr" class=""><div class=""><div class=""> * `<font face="monospace, monospace" class="">public</font>`</div></div></div></div><div class=""> * `<font face="monospace, monospace" class="">module</font>`, the default (currently `internal`).<br class=""> * `<font face="monospace, monospace" class="">file</font>` (currently `private`)<br class=""> * `<span style="font-family:monospace,monospace" class="">private</span>` (no current equivalent: containing scope whether class, struct, enum, extension, etc)</div><div class=""><div class="h5"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">Perhaps this could let us deprecate/remove the keyword `<font face="monospace, monospace" class="">internal</font>`, I'm not sure of many circumstances when you'd actually need to write it.</div><div class=""><br class=""></div><div class="">I also think that `<span style="font-family:monospace,monospace" class="">private</span><font face="monospace, monospace" class="">(module)</font>` is also more intuitively understood than `<span style="font-family:monospace,monospace" class="">internal</span>`.</div><div class=""><br class=""></div><div class=""><b class="">My reasoning:</b></div><div class=""><br class=""></div><div class=""><div class="">This seems to come down to:</div><div class=""><ul class=""><li class="">It lowers the cognitive load if you can put related concepts in the same file.<br class=""></li><li class="">It lowers the cognitive load if you can reduce the number of things a class needs to understand.</li><li class="">People like the current system, its simple and it works for them.</li></ul></div></div><div class="">"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - The Elements of Programming Style<div class=""><br class=""></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" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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 class=""><br class="">
> On Jan 25, 2016, at 5:47 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
><br class="">
> on Mon Jan 25 2016, Ilya Belenkiy <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
>>> Why should the compiler enforce this? That’s my design decision.<br class="">
>><br class="">
>> It would enforce whatever design decision you make.<br class="">
>><br class="">
>>> For the same reason the compiler does not enforce where I have to<br class="">
>>> put „private“ (it can make suggestions like many IDEs do and offer<br class="">
>>> fix-its, like „this method can be made private as it is not used<br class="">
>>> outside the class“ or „this class can be put into its own file as<br class="">
>>> its private methods are not used by other components in this file“.<br class="">
>><br class="">
>> But once you do put it, it enforces it, and that’s the whole point of having access control.<br class="">
>><br class="">
>>> No, there is a clear difference: making the type name part of the<br class="">
>>> variable name enforces no compiler checks whereas putting something<br class="">
>>> into different files does.<br class="">
>><br class="">
>> Similarly, putting all of the source code in the same file is<br class="">
>> equivalent to no checks.<br class="">
><br class="">
> The place where I'm most concerned about this is in playgrounds. If<br class="">
> we're going to use them to teach programming, it should be possible to<br class="">
> demonstrate encapsulation there.<br class="">
><br class="">
<br class="">
</span>Using playgrounds for teaching is a great example of a use case for this. Thanks for mentioning it!<br class="">
<br class="">
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 class="">
<br class="">
-Matthew<br class="">
<div class=""><div class=""><br class="">
> --<br class="">
> -Dave<br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div></div>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>