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
> <[email protected]> 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
> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
