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