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

[Paul Cantrell]

> On Dec 22, 2015, at 6:24 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
>> On Dec 22, 2015, at 9:03 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I weigh the safety argument against the many long hours I’ve spent beating my head against library behaviors, wishing I could read UIKit’s source code, wishing I could tweak that one little thing that I can’t control, and being grateful for the dubious workaround that saves the day — yes, even when a subsequent OS update breaks it. I know what I’m getting into when I solve a problem with a hack, and if the hack ships, it’s only because I weighed the risks and benefits. We app developers rely on swizzling, dubious subclassing, and (especially) undocumented behavior far more often than any of us would like. It is just part of the reality of making things ship — and an important part of the success of Apple’s app ecosystem.
> 
> The same argument implies that we never should have created Swift as it is; that leaving everything dynamic everywhere is necessary so people can get their work done.  In some ways it’s a self-fulfilling prophecy.  I once knew a programmer that argued that all properties/ivars should be public, in case you need to go in and work around some problem.  Naturally, he “needed" to take advantage of that public exposure all the time.  I predict that, as Swift does more to disallow unintended effects, you’ll start to see fewer and fewer of the kinds of problem that require these dubious workarounds.

Well, coming from a “strong static types or bust” background, when I first worked with Ruby I was shocked at how the world did not fall apart even though everything is open to monkey patching! It’s definitely a different mindset — but one in which people exercise careful thought, and write good, reliable software. This stunned me when I first encountered that world, but it’s an empirical fact that it can work quite well. The ways in which it succeeds forced me to rethink a lot of how I approach code.

That said, the “everything dynamic and rewirable” way is _clearly_ not the Swift way, and with “The same argument implies…,” you’re misreading my argument.

In principle, I lean in favor of final by default. It’s clearly more consistent with Swift’s approach. I’m just pointing out that there will need to be something of a culture / ecosystem shift if the platform follows Swift’s lead toward more defensive programming and tighter control. The approaches that have been working for Objective-C library authors, including but not limited to Apple, will not continue to work as is.

>> 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.
> 
> No, it’s nothing to sneeze at; it is essential for creating reliable software.  As a library author, I support anything that helps produce that level of care :-)

Yes: a high level of care, and also open communication, and faster turnaround, and good listening, and … well, exactly the sort of effort Apple is putting forth right now for Swift!

Cheers,

Paul