> 1) Unless you know exactly what a subclass should do, you can not make
> assumptions about when a subclass should call its super implementation.
afaics, the majority agrees on this
> 2) I think it would be desirable if the default behavior is that a subclass
> is expected to call super in methods it overrides, not doing so should be a
> compile warning. This will be the general case, and I think it should be the
> default behavior.
I've been a fan of this since the first "all methods should be final" debate
(imho it's a good compromise), but now the situation is more complicated
because of the the differentiation of same-module overrides vs. external
subclasses (after all, this feature could be modelled as yet another access
level: public < open < "replaceable")
> 3) I think you should be able to silence that warning somehow. I am thinking
> something like:
> override! func setFrame(...) { // note the ! at the end of override
> // not calling super
> }
That was my favourite for overriding of methods that are neither final nor
open. Imho the link between the "!" and the omission of the super-call isn't
that intuitive, but as it is reused in 5), I'd view it as a general indicator
for "I know what I'm doing".
> 4) There should be a macro / swift keyword that specifies that there is no
> need to call super. Something like @discardableFunc would be close to the
> existing @discardableResult annotation in Swift 3. This should be added to
> all functions where the default implementation is empty or unimportant etc.
This is coupled with 2) — but imho there should be a name/keyword for each
option, no matter which one is default, so that discussion can be split into
two parts ("how should it be called?", "what should be default?")
> 5) There should be a macro / swift keyword that specifies that the subclass
> is not allowed to call the super implementation. @deposedFunc? A native
> English speaker can properly come up with a better name. There are a few
> cases where this is relevant; NSOperations start() function is not allowed to
> call super. Using this keyword should make it a warning to call super and
> again I imagine that should also be silenced by using override! in case you
> are forced to call super anyway for some reason.
+1
Afaics, inheritance hasn't been covered yet, but the rules should be simple:
Making the call to super mandatory should always be possible, only the opposite
would be problematic.
A full-fledged proposal imho should also include a paragraph about
"interception":
override func foo(input: String) {
super.foo(input + " bar")
}
override func bar() {
if condition {
super.bar()
}
}
I wouldn't want to forbid either case, but they add a small amount of danger
(compared to neutral monitoring), so it should be justified.
- Tino_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
