[swift-evolution] final + lazy + fileprivate modifiers

[Xiaodi Wu]

_Potentially_ meaningful, certainly. But what I'm hearing is that it isn't
actually meaningful. 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.


On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sabre at nondot.org> wrote:

> I don't fully agree: you are right that that is the case when writing
> code.  However, when reading/maintaining code, the distinction is
> meaningful and potentially important.
>
> -Chris
>
> On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> If the overwhelming use case is that developers should pick one over the
> other primarily because it looks nicer, then blindly click the fix-it when
> things stop working, then the distinction between private and fileprivate
> is pretty clearly a mere nuisance that doesn't carry its own weight.
> On Sun, Feb 12, 2017 at 13:33 Jean-Daniel via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <
>> swift-evolution at swift.org> a écrit :
>>
>> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> *Final*
>> Can someone tell me what is the use of 'final' now that we have 'public'
>> default to disallowing subclassing in importing modules? I know that
>> 'final' has the added constraint of disallowing subclassing in the same
>> module, but how useful is that? Does it hold its weight? Would we add it
>> now if it did not exist?
>>
>>
>> As Matthew says, this is still important.
>>
>> *Lazy*
>> This one is clearer: if Joe Groff's property behaviors proposal from last
>> year is brought forward again, lazy can be demoted from a language keyword
>> to a Standard Library property behavior. If Joe or anybody from the core
>> team sees this: do we have any luck of having this awesome feature we
>> discussed/designed/implemented in the Swift 4 timeframe?
>>
>>
>> Sadly, there is no chance to get property behaviors into Swift 4.
>> Hopefully Swift 5, but it’s impossible to say right now.
>>
>> *Fileprivate*
>>
>> I started the discussion early during the Swift 4 timeframe that I regret
>> the change in Swift 3 which introduced a scoped private keyword. For me,
>> it's not worth the increase in complexity in access modifiers. I was very
>> happy with the file-scope of Swift pre-3. When discussing that, Chris
>> Latner mentioned we'd have to wait for Phase 2 to re-discuss it and also
>> show proof that people mostly used 'fileprivate' and not the new 'private'
>> modifier as proof if we want the proposal to have any weight. Does anybody
>> have a good idea for compiling stats from GitHub on this subject? First of
>> all, I've always found the GitHub Search quite bad and don't know how much
>> it can be trusted. Secondly, because 'private' in Swift 2 and 3 have
>> different meanings, a simple textual search might get us wrong results if
>> we don't find a way to filter on Swift 3 code.
>>
>>
>> I would still like to re-evaluate fileprivate based on information in the
>> field.  The theory of the SE-0025 (https://github.com/apple/
>> swift-evolution/blob/master/proposals/0025-scoped-access-level.md) was
>> that the fileprivate keyword would be used infrequently: this means that it
>> would uglify very little code and when it occurred, it would carry meaning
>> and significance.
>>
>>
>> Infrequent use and significance are orthogonal.
>> I still think developers would declare all ivars private (this is less
>> ugly and shorter), and then will happily convert them to fileprivate each
>> time the compiler will tell them they are not accessible somewhere else in
>> the file.
>> As the code that try to access that ivar is in the same file anyway, it
>> has full knowledge of the implementation details and there is no good
>> reason it shouldn’t be able to access the ivar when needed.
>>
>> We have a problem with evaluating that theory though: the Swift 2->3
>> migrator mechanically changed all instances of private into fileprivate.
>> This uglified a ton of code unnecessarily and (even worse) lead programmers
>> to think they should use fileprivate everywhere.  Because of this, it is
>> hard to look at a random Swift 3 codebase and determine whether SE-0025 is
>> working out as intended.
>>
>> The best way out of this that I can think of is to add a *warning* to the
>> Swift 3.1 or 4 compiler which detects uses of fileprivate that can be
>> tightened to “private” and provide a fixit to do the change.  This would be
>> similar to how we suggest changing ‘var’ into ‘let’ where possible.  Over
>> time, this would have the effect of getting us back to the world we
>> intended in SE-0025.
>>
>> -Chris
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170212/15406731/attachment.html>