[swift-evolution] final + lazy + fileprivate modifiers

[Chris Lattner]

> On Feb 12, 2017, at 12:35 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't actually meaningful.

Yes, for sure.  That was carefully worded :-)

> Here's why:
> 
> If I see `fileprivate` and can understand that to mean "gee, the author _designed_ this member to be visible elsewhere inside the file," then it's actually meaningful. OTOH, if I see `fileprivate` and can only deduce "gee, the author mashed some button in his or her IDE," then it's not really telling me anything.
> 
> What you've said above, as I understand it, is that it's not currently meaningful to see `fileprivate` because the migrator is writing it and not the author. The improved approach you proposed is the additional warning. In that case, the compiler will help to ensure that when I see `fileprivate`, at least I know it's necessary. But that's only telling me a fact (this member is accessed at least once outside the private scope), but it's still machine-based bookkeeping, not authorial intent.

I see what you’re saying, but from a mechanical perspective, I disagree: seeing fileprivate in this (theoretical) world would be more meaningful than seeing private, because you know that there must be something in an extension that uses the member.

That said, whether it is meaningful or not is really not the question.  Assuming you agree that it would carry “some” meaning, the question is really whether or not that meaning carries its own weight in terms of complexity in the language footprint.  I tend to think “no”.

If you agree with “no", then Swift 4.x should eradicate fileprivate as a concept and that we should revert SE-0025 from Swift 4 mode.  What to do with Swift 3.x still hangs in the balance of course.

-Chris