> “this method is private but overridable,” +1 ;-) It would make the language more orthogonal — but I'm afraid this option died when "open" was added, and I have to admit that it would make things complicated as well: Methods that shouldn't be called directly (like UIView.draw and layoutSubviews) might require calls to super, and I don't expect that the recently pitched proposal for "typeprivate" will reach the review phase.
If the patterns discussed are generally considered to be a bad fit for Swift and merely legacy, instead of changing the language itself it could be feasible to tinker with the tools instead: - Smart autocompletion could hide methods that shouldn't be called (and place didDeselectRowAtIndexPath at a less prominent position than the more important didSelectRowAtIndexPath ;-) - The skeleton for an override could include a call to super if it is needed, which would save a whole bunch of keystrokes I think there is big potential in the fact that Swift is designed in the same company that builds the most important IDE for it, which could be leveraged with annotations that don't affect the compiler:
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
