[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[David Waite]

> On Apr 6, 2017, at 5:10 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md <https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>
> What is your evaluation of the proposal?
Just barely +1.

It is a tough choice on whether this is a good change, because various future proposals which have been discussed would be impacted by the change:

- If we add the ability in the future for extensions in the same type to declare stored properties, this influences the behavior of that feature (in potentially both good and bad ways)
- If we add further access controls above ‘private’ in the future, the weakening of private as strongest access control may affect the cleanliness/completeness of that design.

Unlike the API design guidelines, access control levels don’t seem to have common usage patterns amongst the Swift community, with different desired levels of protection within a module (below ‘internal’). This makes the use of “file private” much more opinionated IMHO - widening private just enough that it might even become a common consideration that use of  “fileprivate” is a potential code smell. The need to use “fileprivate” means that details of the implementation of a type may be selectively be exposed to other types, causing higher coupling, causing more code to be placed into a single file, and thus reducing overall maintainability. Similar to the use of IUOs, forced unwrapping and try! , this may still be desirable, and the complexity and impact can be managed appropriately.

So +1 because the decision is being forced for the Swift 4 timeframe, without the ability to evaluate it in scope of a future Swift release that might focus on submodules or extensions with stored properties. Given a crystal ball, i might pick differently.

> Is the problem being addressed significant enough to warrant a change to Swift?
Yes, although I personally don’t like that we are still designing access control incrementally.

> Does this proposal fit well with the feel and direction of Swift?
I feel it fits well with current Swift, but is being forced to be evaluated in a vacuum in terms of future Swift direction. 
 
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study

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