Idea that myself and <@U60PZ2A76> have been discus...

# language-proposals

[Elijah Verdoorn]

Idea that myself and @Charles have been discussing: a new keyword on function definition to automatically make the first operation of said function be a call to super. For example:

override fun onDestroy() {
    super.onDestroy()
    channel.close()
}

could become

super fun onDestroy() = channel.close()

The override word becomes optional, since the call to super only makes sense in the context of functions that are being overridden.

[Zac Sweers]

that looks super fun

[Luke]

continue fun onDestroy() = channel.close()?

[Charles]

continue loses some of the connecting glue for me.

[Elijah Verdoorn]

continue is interesting to me, it reads nicely in english, but super is pretty well-recognized syntax from other languages and might be more natural for developers coming to Kotlin for the first time from other languages

[raulraja]

what happens when you don’t want to call super in the first statement of the override? There are other use cases where you may want to run other stuff before calling super. For example for people that model trees as visitors and the super call order can determine whether you traverse the tree DFS vs BFS if the parent accept traversals on its children.

[elizarov]

I would rather make it a part of a more general “function delegation” framework than a specialized feature, so that this particular case can be written something like that:

fun onDestroy() by withSuper { channel.close() }

This way, calling “super first” will not be hard-coded, but will be just one way to do it. Having said that, I’m not even sure that supporting super calls in function delegation worth it.

[Charles]

You could still call super.* in any normal override.

In my current project this would be used nearly 1000 times. So many overrides (especially in Android) you have to follow this pattern. And it becomes code bloat.

[Charles]

@raulraja Seems to me that solving the before and after cases (leaving the mixed in case alone) would be quite useful in a functional world.

[gildor]

Oh, function delegation would be such a great feature, especially if you could inspect function declaration including annotations. I see many cool usecases for this

[raulraja]

@Charles yes this exist in FP recursion schemes in relation to folding trees and other structures for the visitor example I mentioned above, it's usually variations of fold and unfold but instead of being related to calling super it's modeled with a parametric F type parameter that all foldable data types can implement. I still think that for the case of removing boilerplate calling super, property delegation as @elizarov and @gildor mentioned is a better path and adds less to the lang with much more power for other use cases.

[cbruegg]

What benefits does this idea provide? This is another keyword learners have to get to know

[Elijah Verdoorn]

As an Android developer, this would reduce my overall lines of code in my project - as @Charles noted, there are thousands of cases in Android projects where it is required that the first call in an overriding function be a call to super. I like the generalization that has been proposed around function delegation, seems like the addition of that feature would not only enable this use-case, but also be a powerful addition to the language as a whole

[raulraja]

This can be easily built as a compiler plugin if you use @super instead of super. With the upcoming release of Arrow meta around October this is just a matter of intercepting the parsed AST and in every function that contains an annotation for @super rewrites its body to call super first and write any boilerplate you wish. Similar as to how its done in this other plugin https://github.com/47deg/arrow-meta-prototype/blob/rr-typeclasses-plugin/compiler-plugin/src/main/kotlin/arrow/meta/typeclasses/TypeClassesPlugin.kt#L43