[swift-evolution] Add code to super methods.

Tino Heth 2th at gmx.de
Mon Nov 28 09:50:53 CST 2016


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161128/a407fdbc/attachment.html>


More information about the swift-evolution mailing list