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

[David Waite]

> https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
> What is your evaluation of the proposal?
-1

> Is the problem being addressed significant enough to warrant a change to Swift?
After what seemed like endless discussion, I remain unconvinced that its actual stated motivation justifies its inclusion.

The justification appears to be that there needs to be some way to protect portions of a single source file from one another. A better approach here from my personal experience is just to require developers to have responsibility for understanding the functioning of all the code in a file before making changes, and to structure your code so that you use multiple files to represent different concepts.

The example in the detailed design shows an extension in the same file where counter and advanceCount are not visible to an extension. However, there is nothing to prevent a developer who wishes to use advanceCount to implement a private incrementTwice from putting their code within the class itself, rather than in an extension - literally a difference in insertion point of the same code, and providing the same external behavior.

One use I can partially agree with is that a local scope would allow playground users to more easily experiment with scopes. However, it does not make sense to teach access control with playgrounds unless one is able to show the usage of other scopes - and adding another access control level which students need to keep in their head seems a counterintuitive approach to teaching.

I believe this proposal is mostly motivated by the impedance mismatch between ‘private’ in other languages meaning that access is restricted to a type implementation body or similar, while ‘private’ in swift limits access to the current file. While I can understand someone preferring the system they are more familiar with (especially in the face of private requiring a particular code structure), I don’t believe the additional access model complexity is justified in supporting both.

I expect developers would gravitate toward using one or the other. Other aspects of Swift currently push for file-level access control semantics, such as implementing Equatable for a type based on its internal state. As such, I don’t know if “local” would be used even in contexts where it might be a slightly better fit - developers will already be required to use file-level access control to implement other things.

I will second Joseph Lord’s inquiry for anyone code which has had negative impacts to its safety by the lack of this feature - specifically interested in cases where the file based access control was insufficient, rather than cases where file based access control was not attempted to be used.

> Does this proposal fit well with the feel and direction of Swift?
I don’t know of any v3 goals this aligns with.

My understanding is that this comes about from a simple idea - someone wants to have objects which have some protection of their API from the outside world, and to limit the interface between those objects from exposing internal implementation details in order to maintain invariance. Today, this is done by making the interface between objects internal, and putting the objects in separate files so that they can have private implementation details. Where this can fall down is when you want the API between objects to not be exposed to other members of a module.

Therefore, I wonder if an alternate direction for Swift evolution would be to promote the creation of many smaller modules vs a few large frameworks. Approaches which come to mind for this would be to have submodules as part of a single framework, or otherwise optimize the language, packaging, and/or runtime platform to promote the idea that ‘micro frameworks’ containing less than a half dozen types and as little as 100 lines of code are appropriate and will not have a deployment or runtime impact.

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Most of my experience implementing frameworks has been on top of Java, C#, C++, and Ruby.

The existing public/internal/private system I believe compares favorably with these languages. I don’t believe any of these languages have a file-level limit of object accessibility, instead having ‘private’ be similar to the local lexical scope defined here. Rules about exposure of private methods when you have inner/outer types vary, as do accessibility of private methods through type introspection. As stated above, I suspect some motivation behind this proposal are the difference in ‘private’ as defined in other languages vs in Swift - but I don’t believe both are justified in being present in the language.

> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Significant participation in discussion before proposal.

-DW

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