[swift-evolution] Idea: using 'super()' as syntactic sugar for 'super.overriddenmethod(...)'?

[William Shipley]

In cases like this:

    override func loadView() {
        super.loadView()
        view.addSubview(segmentedControl)
        segmentedControl.translatesAutoresizingMaskIntoConstraints = false
        segmentedControl.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true
    }

or

    override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
        if let destinationController = segue.destinationController as? ScaleViewController {
            scaleViewController = destinationController
            destinationController.scalable = self // weak back-link
	}
        super.prepare(for: segue, sender: sender)
    }

We obviously need the ability to manually place the call to ‘super’ in our overridden methods, so we can’t just have the compiler always automatically call super (like it does with dealloc).

But only occasionally do we need to pass in different parameters to the superclass method than were passed into us, and it’d be nice to ⑴ not have to do all the extra typing / reading in the common case, ⑵ makes it clear at a glance we’re calling the _same_ method on our superclass, not accidentally calling a different one, and ⑶ make it especially noticeable when we ARE changing the parameters around to our call to super by having that be the only version where you need to specify them.

So, for instance, the above two methods would turn into:

    override func loadView() {
        super()
        view.addSubview(segmentedControl)
        segmentedControl.translatesAutoresizingMaskIntoConstraints = false
        segmentedControl.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true
    }

or

    override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
        if let destinationController = segue.destinationController as? ScaleViewController {
            scaleViewController = destinationController
            destinationController.scalable = self // weak back-link
	}
        super()
    }

But this contrived example would stay the same:

    override public func mouseDown(with event: NSEvent) {
        let someOtherEvent = …
        super.mouseDown(with: someOtherEvent)
    }

Note that I just made up a contrived example here because I couldn’t find a single real-world case in my 33,098 lines of Swift code where I call super.blah(…) with different parameters than the ones that were passed in, which I think also points to why this syntactic sugar is sweet and low-cal. (The only time I saw super being called with different parameters was in init() methods, where I was calling a different initializer.)

—

Another version would be to use a new word instead of “super()”, which doesn’t overload the noun-ish-ness of ‘super’:

	overridden()
or
	superfunc()


It’s possible that the empty parenthesis in “super()” would confuse readers into thinking some other version of their function is being called (that has no parameters), so it’s worth considering if something like “overridden” by itself (no ()) would be better. I think if this is a worry I’d prefer to use three dots to indicate more stuff is going on here, to match with our documentation:

        super(...)
or
        overridden(...)

An orthogonal idea is for the contrived example would be to allow new parameters to be passed in directly without typing the function name again:

        super(with: someOtherEvent)
or
        overridden(with: someOtherEvent)


-Wil


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170926/56e3c8c0/attachment.html>