> On Apr 6, 2017, at 5:10 PM, Douglas Gregor via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
