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

Andrey Tarantsov andrey at tarantsov.com
Wed Dec 23 22:04:58 CST 2015


> Aren't we mixing up two different issues here? "Having a default final for Swift classes" should be treated as a separate issue from "Apple frameworks should stay overridable".

I have to agree, and so I'll change my vote to +1.

>  1. Within a module, should I be able to override my own classes / methods by default, or should I have to explicitly mark those classes as overridable to do that?

Definitely not — explicit is preferred, mostly for documentation purposes (I don't think there's much safety to be gained within your own module). Perhaps because in my code, overridable methods are perhaps 1% of all.

>  2. If I'm releasing a Swift binary framework, and I haven't yet thought about which classes / methods should be overrideable, should I release it in 
>  everything-is-overridable mode, or in nothing-is-overridable mode?

That's a tricky one. Ideally you would pretend that nothing is overridable, but some hack like @testable makes everything overridable when really needed.

>  3. If I'm using a third-party (non-Apple) Swift binary framework, and if the framework author hadn't really thought about which classes / methods should be overrideable, would I want the power to override everything in the framework now?

Yes. There were many cases where fixing up a pod was just an important as fixing up an Apple framework.

Yes, I have an option to change the source — but it's vastly more labour-intensive if all you need is a simple isolated change. (Especially if that change isn't likely to be accepted upstream.)

>     (Note that if I get that power, I forgo all hope of getting a binary-compatible update to the framework with correct annotations about which classes can be safely overridden and which aren't meant to be overridden.)

Sure, and that doesn't matter because all frameworks are built with your app anyway.

>  A3: Ideally, I'd like to be able to override everything in the framework I use, but if that implies that I can't get a binary-compatible fix to the framework, maybe I can live without that overridability.

Why would you want binary compatibility for non-Apple frameworks? It's not like you can install them globally (or would want to, even if you could).

A.



More information about the swift-evolution mailing list