> On 12 Feb 2017, at 18:24, Chris Lattner <clatt...@nondot.org> wrote: > > On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
