[swift-evolution] final + lazy + fileprivate modifiers
Zach Waldowski
zach at waldowski.me
Sun Feb 12 18:16:52 CST 2017
I vehemently agree on these points. New-private and fileprivate "[add]
more information" to a file the same way requiring `self.` and other
sorts of visual noise that Swift normally eschews.
I wish for the Swift community to be introspective enough to count both
its successes and failures. SE-0025 was a botched addition to the
language. That the migrator did such a bad job is evidence of its poor
overall consideration. Adding a fix-it strikes me as the compiler
waggling its finger at me for code that would've been perfectly fine in
the past, something that it is not at all true with the "let" fix it;
accidental mutation has been discussed a ton by the larger programming
community, not-so-much for obscure access control mechanics.
It's perplexing that fileprivate advocates continue to stand on mostly
theoretical benefits about new-private. I feel nothing for the
mathematical purity about the types in a file. In practice, I can with
much experience now how awful it is. There has been no end to the
confusion its introduction has inflicted upon my team(s), people new to
the language, and people revisiting the language:
- My teams and coworkers are less effective at code review from constant
litigation about access control. "'Did this need to change?' / 'No, it
was just the migrator.'" has become a disturbingly common refrain.
- New users are just struggling to figure out where to put the curly
braces in the first place. Having to make them check and re-check
where things go in a file, or just tell them to use this clunky get-out-of-jail-
free keyword, feels like visiting a special kind of Pythonic hell on a
language I otherwise love and love to teach.
- People returning to the language feel (and often say - just look at
Twitter) Swift has a lot of syntax, and are frustrated that the
addition of a new keyword was burned on adding something that amounts
to mostly a stylistic opinion.
All the best,
Zachary Waldowski
zach at waldowski.me
On Sun, Feb 12, 2017, at 04:45 PM, Xiaodi Wu via swift-evolution 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.
>
>>> 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
>>>
>>> _______________________________________________
>>> 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/e463e8d3/attachment-0001.html>
More information about the swift-evolution
mailing list