[swift-evolution] Final by default for classes and methods

[Drew Crawford]

> On Dec 22, 2015, at 11:03 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’m not totally opposed to final by default. Joe’s arguments sway me in principle. In practice, if Swift does indeed moves us toward “less wiggle room, less hackable” by default, then that wiggle room _will_ have to come from somewhere else: perhaps more open sourcing and more forking, or faster turnaround on fixes from library authors, or a larger portion of time spent by library authors explicitly exposing and documenting customization points. The new effort involved for library authors is nothing to sneeze at.

> On Dec 21, 2015, at 11:50 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:

> Of course Apple code will have bugs in it. Trying to patch over these bugs in your own code is (1) obviously not an answer Apple would support, but also (2) fraught with peril, and (3) likely to break in the next OS release.
> 
> TLDR: It's already unsafe to do this with the existing set of Swift features. Yes, this makes things "worse", but it's not something we're interested in supporting anyway.

I actually agree with making final default.  But I think it's important to understand the consequence.  "One does not simply" seal all the classes.

I'm going to repeat publicly something that third-party developers (including me) have been talking about privately for over a year.  We're going to end up moving to open-source, community-maintained frameworks (a la swift-corelibs-foundation), and away from closed-source Apple-maintained dependencies.

This isn't the place to rehash the whole tired history of it, but to provide a little context: I alone have 217 open, non-duplicated radars under my main account.  That is a lot of radars.  The problem resolution strategies available to third-party developers are very very bad.  Subclassing is one of those "bad" resolution strategies that everybody agrees is awful, but what are you going to do, rewrite the core Apple frameworks by yourself?

Yes, as it turns out.  Many of us were pleasantly surprised (and some of us literally could not believe) Apple's support for this effort with swift-corelibs-foundation.  But I think (some) on this list may be unprepared for the full extent to which the community will be taking on an active role.  I actually have a whole queue of patches in the basement that predate swift-corelibs-foundation completely that I will be sending upstream slowly, and what gets rejected will be third-partied somewhere.  That's before we even get to the question of replacing some of the other technologies that don't appear on github.com/apple <http://github.com/apple>.  

IMO making the transition to "open" frameworks that we can actually fork/fix/bundle ourselves is the Right Solution™ to this whole "final" debate, but I think it is important to preview for everybody involved that this is the straw on a very overworked camel.  I had to subclass UIKit yet again just a few days ago.  Paul Cantrell is 100% right that the wiggle room will have to come from somewhere. 

The wiggle room will come from the community stepping up and making our own tools.  That has been happening to some extent in the dark, but presently it will be happening in the daylight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/3e9e2926/attachment.html>