> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
