[swift-evolution] Add code to super methods.

[Haravikk]

> On 20 Nov 2016, at 16:00, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> I'm not sure I follow your meaning on omission; I quite like Sean's suggestion of having an override(before) or override(final) in the sub-class, this way the call is explicitly auto-generated. I think having it be added automatically in the regular override case could be a bit confusing, I think a warning or error is better in that case as it should be visible so you know exactly when it is being called, the other cases don't need it (as they have the extra information on the override).
> It's always possible to construct examples where there order is important, but I guess those won't matter in real code — and it would feel very strange to me if one of the print-statements would cause an error:
> override func f(input: Int) {
> 	print("Before")
> 	super.f(input: input)
> 	print("After")
> }
> 
> (even commands after a return statement compile just fine…)

I think I covered that, though it's a bit of a tricky situation; ideally a restriction shouldn't cause either of those print statements to cause an error, as they have no side-effects to self. The problem is detecting that, as we don't currently have any exposure of pure functions, and no way of knowing that a method of a reference type is mutating or non-mutating yet. I've raised it mainly for discussion as I'm not 100% sure of what we'd need to make it work.

If it isn't possible just yet though then the before and after attributes could always be delayed until later when non-mutating reference methods and pure functions can be reliably accounted for. This means that an initial release would be for the required, optional and never attributes to determine whether super has to be called, and error/warning to tweak the severity of that restriction.

I do still like the idea of allowing sub-class developers to use override(before) and override(after) to generate the super call for them regardless; while it may seem minor it allows you to focus in on what you're changing, but does have the slight added advantage of being its own scope, i.e- since you mentioned defer before, in an override(after) method the defer would be called before the automatic super method.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161120/471cb351/attachment.html>