What is your evaluation of the proposal?
+1, it would improve my team's codebase.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
In our case we are using extensions very liberally to organize our
code, and we are using fileprivate just for having access to stored
properties from extensions. A quick search tells us that in our main
target:
- fileprivate: 1483 uses
- private: 424 uses
So it's roughly 3.5x for fileprivate for us. Most of those private
uses are private extensions, where we keep all of our private methods
organized (and that way we don't have to specify that level for every
method). But we cannot do the same for stored properties and we are
forced to use the keyword again and again, several lines in a row.
The problem is that *we never want to use fileprivate*, we are just
*forced to use it*. After a while it's a habit, but it's just ugly to
look at and the code is harder to read. We don't want to have that
detail in our head, in the same way that Swift removes other
unimportant details that we had when working with just Objective-C.
Being selfish, expanding the notion of private to extensions within
the same file would be enough for us. But we also don't see any
additional value in having the fileprivate keyword, and while there
are several code styles that lead to good code, we don't think that
code styles that access other types private information leads to good
design.
Does this proposal fit well with the feel and direction of Swift?
Yes. This changes was implemented having no references from other
languages, and with zero experience in shipping code. Now we have that
experience, and it shows that for a significantly part of the
community this was hurtful. The fact that with a popular code style
fileprivate is used way more than intended tells something about this.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
While I have no experience with any fileprivate/private language, the
current scope distinctions are hard to explain. At first sight it's
weird that for file-level declarations private and fileprivate means
the same, even if it makes sense when you think about it.
The fact that other popular languages with scope-based access don't
have extensions means that maybe we cannot model Swift scopes based on
them.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study and shipping experience with private since Swift 2 and
with fileprivate since Swift 3 was released.
···
--
Víctor Pimentel