[swift-evolution] Add code to super methods.

[Aron Lindberg]

I have also been considering something like this for stage 2, but since we are discussing it now this is what I think would be most feasible:

1) Unless you know exactly what a subclass should do, you can not make assumptions about when a subclass should call its super implementation. This is truer the more general the class is. Take the method setFrame on NSView as an example; We might want to save some state before calling super, we might want to tweak the input parameters before sending them on to super, and we properly want to perform some custom view logic after calling super. NSView have no way of knowing when you should invoke super in a subclass.

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.

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
}

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.

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.

Please let me know what you think, but I think a formal proposal should wait to stage 2.


> On 25 Nov 2016, at 17.36, Kevin Nattinger via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I agree. An NS_REQUIRES_SUPER equivalent was on my list of things to propose during stage 2, and I don't see a reason to enforce order. 
> 
> 
> On Nov 25, 2016, at 04:42, Tino Heth via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>>> What are your thoughts on this?
>>> 
>>> Just to throw out a strawman:
>>> 
>>> // Warn if override doesn’t begin with “super.foo()”
>>> __attribute(swift_requires_super_call_at_begin) 
>>> 
>>>  // Warn if override doesn’t end with “super.foo()”
>>> __attribute(swift_requires_super_call_at_end)
>> 
>> I myself would already be happy if Swift had an equivalent to NS_REQUIRES_SUPER (preferably with a different name ;-).
>> The ability to indicate that super shouldn't be called when overriding would be nice as well — both situations happen in Cocoa, and it isn't enforced, but only documented.
>> 
>> I don't have any examples where the position of the call to super matters, and my personal opinion is that this feature wouldn't pay off:
>> Of course, there are situations where order is important — but as with willSet/didSet, it might only be important for the overriding class, not for super.
>> 
>> - Tino
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161128/87c15388/attachment.html>