[swift-evolution] [Draft] Fix Private Access Levels

[Joanna Carter]

> For example, I had to split this class into multiple files using extensions:
> https://github.com/smud/Smud/blob/master/Sources/Smud/AreaFormatParser/AreaFormatParser.swift<https://github.com/smud/Smud/blob/master/Sources/Smud/AreaFormatParser/AreaFormatParser.swift>
> I had to remove 'private' modifier from all variables and functions. Now class implementation details are exposed to the entire module. 'Fileprivate' was of no use in this situation. If there was an ability to mark them as `private to type + extensions`, I would use this access level instead. In fact, in 99% of use cases I needed that exact behavior and not 'internal to module', so I also proposed making it the default.

I was used to using partial classes in C#, to separate partial concerns in a single type. Swift extensions give us similar behaviour but, at the moment, I would rather be programming in C# than Swift when it comes to visibility control.

> In other words, current visibility system doesn't work for my coding style (splitting classes into multiple files), nor it will work after rolling back private behavior. It could become useful if the concept could be exteded to mean "fileprivate + its extensions private". It would allow protecting other classes in the module from accessing implementation details of the current class. It's sad that many people are opposed to this concept.
> 
> On separate 'scoped' access, I agree that it may be redundant.

I've still to get a grip on what is meant by 'scoped' access. The only way I see it is as a file/module based approach as opposed to a type based approach.

> To summarize, I propose reverting "private" to mean "fileprivate" but extending it to extensions as well. This way both coding styles could be used: putting everything in a single huge file or splitting the class into multiple files or mixing these approaches. Ideally, I think it should be the default access level leaving only "public" and "internal" keywords to be set explicitly.

Certainly, if we can't have a dedicated "extensible" scope for this kind of scenario, then we, at least, need some way to limit visibility of "private" data to a type and its extensions ; so, as much as I really don't like the idea of extending private back to the fileprivate scope, extending private to mean inclusion of its extensions would be really welcome.

Internal is just simply too big for this kind of situation

--
Joanna Carter
Carter Consulting