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

Tino Heth 2th at gmx.de
Tue Apr 11 13:47:33 CDT 2017

>> — It adds no power to the language
>> The proposal solves no real problem, but rather encourages a certain style of programming, which is quite popular among authors of styleguides, but has no clear net gain.
> While your other points are defendable, I have to disagree here. It does bring value to a population of developers (me included) for whom that style of programming adds a lot of readability. It's part of style guides for a reason.
… and it worked well enough, even with only three access levels. Is it really that beneficial to have properties that are only visible to certain extensions in a given file?
If I had a type that
a) implements some protocols (or has some other motivation to be split)
b) has members that should be hidden, but exposed to a single other type (fileprivate would be just fine without this premise)
c) has no other members that should be shared with a different alien type (that would force us to expose those parts to a type that should have no access)
d) has elements that are so fragile that they should be protected from any other type (SE-0169)
e) at the same time, it has to be fine that those fragile members of a nontrivial type can be accessed from all of its extensions that are located in the same file

SE-0169 would be the perfect answer to such a scenario, but I don't think I will encounter such types often:
As soon as one requirement isn't fulfilled, the whole purpose of those complicated modifiers is defeated, because our type leaks data that should be contained securely.
The construct of fileprivate and private with different meanings offers no fundamental benefit over internal — it just delays the issues it wants to solve a tiny bit.

>> — It diminishes the need for fileprivate without making it redundant
>> It would be nice to get rid of an access level, but having four common ones and fileprivate as an exotic outlier doesn't feel right for me.
> Doesn't the argument of progressive disclosure sway you here? open is already an outlier that only library authors will play with, and that's a good thing. It reduces the number of access level truly useful on a day to day basis, while leaving the others for more narrow purposes.
I would definitely prefer a set of easy to understand access levels over splitting modifiers in two groups, with one set reserved for "experts".
Access levels are a very basic concept, and imho they shouldn't need long explanations.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170411/38629ae9/attachment.html>

More information about the swift-evolution mailing list