This discussion is getting longer than I thought… guess it's because we can't
spend our energy for proposals that introduce new features ;-)
I had some "hope" that SE-0025 would be dismissed when one of the deadlines
passed without an implementation, and I was thinking about proposing to drop it
— but the feature has been finished before I started writing.
Personally, I don't have problems with "new private", but it is a whole access
level that's actually not needed for regular coding:
Considering the importance of playgrounds, it's desirable to be be able to
teach about information hiding, which doesn't work with fileprivate — but real
applications normally consist of several source files, and this use case is
still my focus.
In this setup, the benefit of two access levels whose only difference can be
neutralized by a very tiny reorganization of code is just theoretical.
With Swift 3, the number of access levels nearly doubled, but even with an
impressive number of five options, there are still many intends that can't be
expressed, so we traded a limited (but simple) system for a slightly more
complex one that still lacks power.
What itches me most in this aspect is the strong preference for small, additive
changes, which discourages a holistic take on big topics like this.
swift-evolution mailing list