[swift-evolution] [Review] SE-0025 Scoped Access Level

[Matthew Johnson]

> 
> What is your evaluation of the proposal?
+1.  I believe I was the first person to suggest this as a direction for refining the access control feature.  It fits naturally with the existing access control features, allows more refined expression of intent, and adds minimal incremental complexity to the language.

Differentiating between the intention of ‘local’ and ‘private’ access control is IMO a big win.  When reading code that declares a member ‘local’, I immediately know I only need to consider how other code in the containing scope uses that member.  I do not need to consider whether the member is used by other code in the same file.  The increase in clarity and readability is significant.

During the discussion I looked through the code for the (at that time) current release of Alamofire to see how ‘private’ members are actually used.  As it turns out, every use of `private` in that library could actually use `local` instead if it existed, with a corresponding increase in clarity and readability for anyone new to the code.

In some cases ‘private’ and ‘local’ would be equivalent because there is only one type / scope in the file anyway.  However, in most cases for Alamofire they actually do communicate something different.  There are a few ways this is possible:

In some cases, this is because there is a nested type involved and the `private` members are inside the nested type.  They should not be visible outside the scope of the nested type.  

In other cases, there are extensions of other types.  These extensions add methods that are closely related to the primary type / extension involved in the file.  The private members of the primary type should not be visible to the related extensions.

One other case that didn’t appear in Alamofire, but I have seen elsewhere is a case where you conform several types to the same protocol (usually a simple protocol) in the same file.  In this case there may be helper methods that support the protocol implementation but should not be visible to the other implementations of the protocol that are in the same file.

None of these cases would be covered by various alternatives (related to concurrency, etc) that have been discussed in the review thread.  Scoped access control stands on its on as a small but valuable addition to the language in addition to providing better short-term options for some of the cases discussed in the review until more complete and direct solutions are added to the language.

> Is the problem being addressed significant enough to warrant a change to Swift?
Yes.

> Does this proposal fit well with the feel and direction of Swift?
Yes.  The approach is a very natural extension of the existing access control mechanism.

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
This is closer to the notion of ‘private’ than Swift’s existing ‘private’ access level.  Swift’s ‘private’ solves the ‘friend’ problem much more elegantly than ‘friend’ but it leaves an expressivity gap where members are sometimes much more broadly visible within a file than is necessary.

> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I participated heavily in the discussion leading up to this proposal, including analysis of existing code for places where this feature would be valuable.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160228/d425a3f5/attachment.html>