[swift-evolution] final + lazy + fileprivate modifiers

[David Hart]

> On 12 Feb 2017, at 18:24, Chris Lattner <clattner at nondot.org> wrote:
> 
> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto: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 <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.
> 
> 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.

I’m 50/50 on this idea. If SE-0025 was the right decision, then this is a good suggestion. It will push people towards using fileprivate only when necessary. But it also has the consequence of biasing future stats towards the fact that SE-0025 was a good idea. For example, imagine we had introduced a folderprivate access modifier, and added a warning that pushed towards using folderprivate when internal was not necessary, it would give credit to folderprivate because we would see it in much more code: people just applying the fix-it. But it doesn’t mean anything about folderprivate being a good idea in the first place. Does that make sense?

> -Chris
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170212/6fe931d1/attachment.html>