[swift-evolution] access control

[Ilya Belenkiy]

>>   If we're going to use them to teach programming, it should be possible to
>> demonstrate encapsulation there.

A very important use case. In addition, it would be especially sad if there was a workaround for this particular case, and students learned the concept but could not apply it in real Swift code.

> On Jan 25, 2016, at 8:46 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> 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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/58a11bd6/attachment.html>