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.

- Tino
swift-evolution mailing list

Reply via email to