[swift-evolution] [Discussion] Enforcing Calling Super

[Haravikk]

> On 24 Feb 2016, at 02:07, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Been following the many discussions on this topic and I do not think  that these start/end requirements will ever fly. Imposing such a specific location on the sub-classes will cause a lot of troubles, whether it being unable to add debug log, or to tweak parameters before passing them to super, in the end the developer of the main class won’t dare use such specification, to avoid pushing away potential sub-class developer, and as a way to preemptively mute their complaining.

I mentioned in the previous discussion that before/after shouldn’t really be used in a general sense right now, but when we get abstract classes they will make a lot more sense depending upon what aspect of a type an abstract method actually implements. They shouldn’t be all that common, but when you’re absolutely certain that they’re need then they are important; for example if a parent class could be in an inconsistent state if its super method isn’t called first (meaning any other methods it implements could give undefined results if also used within the child class).

There are definitely use cases for these requirements, they just aren’t the most common, so shouldn’t be placed as restrictions unless you know you absolutely need them. That said, this is partly why the proposals seem to be erring toward issuing a warning as the default behaviour, as this means that a developer can still just ignore it and do what they like anyway, albeit accepting the risks it may involve.

Regarding putting things before the super call such as debug logs and parameter tweaks; this could still be possible if we can think of a good way to handle them, i.e- anything non-mutating could be fine, but the question is how to detect that; I’m not sure if adding such detection is worth the effort to allow niche usage around a niche requirement which, as a warning, you can just ignore anyway.