[swift-evolution] access control

[Matthew Johnson]

> On Jan 25, 2016, at 5:47 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Mon Jan 25 2016, Ilya Belenkiy <swift-evolution at swift.org> wrote:
> 
>>> Why should the compiler enforce this? That’s my design decision.
>> 
>> It would enforce whatever design decision you make.
>> 
>>> For the same reason the compiler does not enforce where I have to
>>> put „private“ (it can make suggestions like many IDEs do and offer
>>> fix-its, like „this method can be made private as it is not used
>>> outside the class“ or „this class can be put into its own file as
>>> its private methods are not used by other components in this file“.
>> 
>> But once you do put it, it enforces it, and that’s the whole point of having access control.
>> 
>>> No, there is a clear difference: making the type name part of the
>>> variable name enforces no compiler checks whereas putting something
>>> into different files does.
>> 
>> Similarly, putting all of the source code in the same file is
>> equivalent to no checks.
> 
> The place where I'm most concerned about this is in playgrounds.  If
> we're going to use them to teach programming, it should be possible to
> demonstrate encapsulation there.
> 

Using playgrounds for teaching is a great example of a use case for this.  Thanks for mentioning it!

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.

-Matthew

> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution