[swift-evolution] final + lazy + fileprivate modifiers

[Xiaodi Wu]

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/687429c5/attachment.html>