> 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
