[swift-evolution] final + lazy + fileprivate modifiers

Sun Feb 12 15:52:09 CST 2017

On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>>
>> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> _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.
>>
>>
>> You’re looking at it backward.  It’s when you see `private` and can
>> deduce “this member is only visible inside it’s declaring scope” that can
>> be really helpful.  *This* is what matters.
>>
>
> In what ways can that information help you?
>
> 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.
>>
>>
>> The important thing is that this machine-based bookkeeping results in a
>> proof about the code.  This facilitates reasoning about the code.  You can
>> make an argument that this proof is not important enough to matter, but you
>> must admit that this is a real concrete gain in information that is
>> immediately available to a reader of the code (after they know that it
>> compiles).  Personally, I find this proof to be valuable.
>>
>
> Comparison has been made to `let` and `var`. In that case, whether a
> variable is mutated can be non-trivial to deduce (as Swift has no uniform
> scheme for distinguishing mutating from non-mutating functions; the ed/ing
> rule has many exceptions). By contrast, here, I don't see any gain in
> information. You can literally *see* where the (file)private member is
> accessed, and when a file gets too long, even a simple text editor can do a
> decent enough find.
>
> If you're right that the real value is that seeing `private` helps you
> reason about the code, then that value must be commensurate to how often we
> see Swift users amending the migrator to take advantage of it. For me, the
> compelling evidence that Swift users don't find this proof to be valuable
> is that, by examination of Swift 3 code, Swift users haven't bothered. If
> we add a new fix-it to force them to, then of course they'll mash the
> buttons, but it's pretty much declaring that they are wrong not to care
> about what it seems they do not care at present.
>
>
> This is really subjective and it’s not clear to me that there is
> substantial evidence one way or another.  I know that `private` is valued
> and used heavily by the teams I have worked with.
>

It wasn't a rhetorical question that I asked: what value do you perceive in
the new `private` in terms of helping you reason through code?

Maybe that’s an exception, but maybe not.  I don’t think we know yet and I
> think this is what Chris is hoping to learn.
>
>
> 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/swif
>>>> t-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
>>>>
>>>
>> _______________________________________________
>> 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/ca2c3622/attachment.html>