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

Andrey Tarantsov andrey at tarantsov.com
Sun Dec 20 15:17:52 CST 2015


This is another proposal that's right on principle, but breaks down in real-world scenarios.

> To play devils advocate, take for example UINavigationController in UIKit on iOS.

This.

Real iOS apps subclass and override things that were never supposed to be overridden, swizzle iOS internals and do a lot of other nasty stuff, because sometimes that's the only way to get the effect you want, and you get to test betas of future iOS releases anyway, so if something breaks, you'll catch it and release a fix.

I'm really worried about the world where monkey-patching iOS internals is no longer possible. Thankfully, a Swift-based UIKit isn't anywhere on the horizon.

ON THE OTHER HAND, I do agree with this proposal for our own code. I've always used

// override point

to mark methods designed to be overridden, and a keyword to document this formally would be appreciated.

A.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/76fe7cd1/attachment.html>


More information about the swift-evolution mailing list