[swift-evolution] final + lazy + fileprivate modifiers
Dimitri.Racordon at unige.ch
Mon Feb 20 08:30:12 CST 2017
I think that fileprivate is fine, and that the drawback of having very large files is acceptable, compared to additional complexity induced by more subtle access control syntax/semantics. fileprivate has the privilege to be easy to understand by *anyone*; extensible, scoped, protected and the likes are not.
Also, I don’t think the expressivity of access control should cover every single case:
* What if I want another type to access my internal properties?
* What if I want another type to access a subset of my internal properties?
* What if I want another type to access a subset of my internal properties in read-only?
* What if I want another *function* to access my internal properties?
I’m sure everybody can find good examples illustrating the above questions, and I’m sure some people already encountered similar situations. I may even agree that in these instances a super-fine-tuned access control might have saved few hours of work, but nobody seem to consider the additional cost of having those in the first place. If it takes days for (in)experienced users to understand the meaning of an access control modifier, plus hours and hours of debating with your team whether some type/function/property should be private, file private, type private, extensible private, module private, etc. the potential time saved by having access control is lost by having to define it properly.
More information about the swift-evolution