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

[Michel Fortin]

> Proposal link:
> 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?

I don't understand the need for this: when you need things to be accessible elsewhere in the file you can already use `fileprivate`. To me it looks like we are trying to change the semantics of `private` to be closer to `fileprivate` simply because `fileprivate` has been labeled as an undesirable.

The motivation section of the proposal talks about "the prevalence of fileprivate" as if that was a horrendous thing. I disagree with this implicit assertion and I will claim that `fileprivate` actually makes a better soft default.

I happen to also disagree that this is a narrow change. It's true that in some files (those with no extensions) this will have absolutely zero impact; in many others (those made of a type and dozen of extensions to that same type) it'll make `private` equivalent to `fileprivate`. While it can be narrow in some cases, in others it is effectively quite similar to getting rid of `private`. SE-0159 was rejected because it removed scoped-private and this is not much different.

In the end, this change might achieve the goal of making `fileprivate` used less often, but only because `private` becomes very close to `fileprivate` in the common case of having a type defined with many extensions as part of the same file. I doubt the small difference between `fileprivate` and `private` that would remain is enough to justify having two access levels. If we were designing from scratch, we'd only keep one of the two and get rid of the other as mostly redundant.


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

I think there is a significant problem with access control, but it is ill defined. There is nothing inherently wrong with the prevalence of `fileprivate` (other than how it's called).


> Does this proposal fit well with the feel and direction of Swift?

I have to admit I find it hard to decipher "the direction of Swift" when it comes to access control since SE-0025. My own direction of Swift now is that I try to use `fileprivate` instead of `private` unless there is a good reason to use `private`. Even though it looks a bit strange at first glance, it has the semantics I generally want.

This proposal might make using `private` work in more cases, so I should be thrilled, right? I'm not that thrilled because with the semantics being closer to `fileprivate` it'll become less obvious which one should be used in which situations.


> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Not sure there's anything left to compare to at this point.


> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read most messages on this topic on the list and replied occasionally.


-- 
Michel Fortin
https://michelf.ca