[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions
david at alkaline-solutions.com
Fri Apr 7 14:35:25 CDT 2017
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution