<div dir="ltr"><div>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><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><br></div><div>Perhaps this could let us deprecate/remove the keyword `<font face="monospace, monospace">internal</font>`, I'm not sure of many circumstances when you'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>"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><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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 class=""><br>
> On Jan 25, 2016, at 5:47 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
> on Mon Jan 25 2016, Ilya Belenkiy <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>>> Why should the compiler enforce this? That’s my design decision.<br>
>><br>
>> It would enforce whatever design decision you make.<br>
>><br>
>>> For the same reason the compiler does not enforce where I have to<br>
>>> put „private“ (it can make suggestions like many IDEs do and offer<br>
>>> fix-its, like „this method can be made private as it is not used<br>
>>> outside the class“ or „this class can be put into its own file as<br>
>>> its private methods are not used by other components in this file“.<br>
>><br>
>> But once you do put it, it enforces it, and that’s the whole point of having access control.<br>
>><br>
>>> No, there is a clear difference: making the type name part of the<br>
>>> variable name enforces no compiler checks whereas putting something<br>
>>> into different files does.<br>
>><br>
>> Similarly, putting all of the source code in the same file is<br>
>> equivalent to no checks.<br>
><br>
> The place where I'm most concerned about this is in playgrounds. If<br>
> we're going to use them to teach programming, it should be possible to<br>
> demonstrate encapsulation there.<br>
><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 class=""><div class="h5"><br>
> --<br>
> -Dave<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">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>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>