[swift-evolution] final + lazy + fileprivate modifiers

[Xiaodi Wu]

What was added in Swift 3 was `private`; the old `private` was renamed
`fileprivate` with no change in behavior. Certainly, submodules are a big
topic that deserves careful consideration. But the question being discussed
here is about rolling back the change that was implemented in Swift 3 by
removing `private` and restoring `fileprivate` to its old name.


On Sun, Feb 12, 2017 at 8:08 PM, Dietmar Planitzer via swift-evolution <
swift-evolution at swift.org> wrote:

> Fileprivate is a feature that should not have been added to Swift 3
> because it is in the end just a needlessly limited version of the Java
> package access level. Fileprivate forces me to put all types which are
> related on an implementation level into the same file while Java packages
> allow me to put each type implementation into a separate file. The only
> thing that Java requires is that all files which are part of the same
> package are tagged with the same package id. Java’s package access level is
> more powerful than fileprivate because it gives me more freedom in how I
> want to organize my code while still making sure that code in sibling and
> parent packages can not access symbols inside my package which form part of
> the implementation details of my package.
>
> The first thing that needs to happen before any more access levels are
> added is that a concept of sub-modules is added to Swift along the lines of:
>
> 1) modules can be organized into a tree with one module as the root.
>
> 2) all modules which are nodes in the same module tree form a single
> resilience domain.
>
> IMO, the sub-module stuff should be designed similar if not the same way
> as Java packages because there are already lots and lots of SDEs who know
> how Java packages work, and Java packages are well understood, simple and
> straight-forward in their mechanics.
>
> Once sub-modules are in place, it makes sense to revisit the access level
> topic. Eg in order to add a “module” access level that represents the scope
> of a module. So “module” could then do what file private can do today plus
> more. But we should stop trying to add more access level to the language
> until then. We also need to look much more at the bigger picture of things
> instead of getting too much hung up on a single component of a larger
> mechanism, when it is that larger mechanism that is primarily interesting
> and relevant.
>
>
>
> Regards,
>
> Dietmar Planitzer
>
> > On Feb 12, 2017, at 16:16, Zach Waldowski via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > 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
> >
> > _______________________________________________
> > 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/ba43915d/attachment.html>