Omit call parameters when a function directly calls another of the same paramters

Would it be a good idea that when a function directly calls another of the same parameter types and order, there is some feature in the language to omit the parameters?

For example if we use ... to omit parameters, it would be like this:

fun fun1(param1: Type1, param2: Type2): ReturnType {
    // implementation
}

fun fun2(param1: Type1, param2: Type2): ReturnType = fun1(...)

This can be quite useful when there is a factory interface that doesn’t know what constructor to call and it has to be an abstract method inside, and there are a lot of classes implementing this interface.

interface FactoryInterface<Data> {
    fun create(param1: Type1, param2: Type2): Data
    // other funs
}
object SomeDataFactory: FactoryInterface<SomeData> {
    override fun create(param1: Type1, param2: Type2): SomeData = SomeData(...)
}

When create and Data constructors have a lot of parameters (much more than 2), doing this can reduce a lot of redundant code that can’t be generated automatically by IntelliJ IDEA. Meanwhile, it doesn’t really impact readability.

Of course I can try this workaround:

interface FactoryInterface<Data> {
    val creator: (Type1, Type2) -> Data
    // other funs
}
object SomeDataFactory: FactoryInterface<SomeData> {
    override val creator: (Type1, Type2) -> Data = ::SomeData
}

But using function type val doesn’t seem to be the commonly accepted practice, and it introduces a little bit of reflection call overhead. It doesn’t seem worth it just for simplicity.

That’s an interesting idea, but I don’t think it goes far enough. I can’t recall needing to do exactly what you illustrate — but I can recall overloading methods by appending extra parameters. So it would be good to specify a sub-range of the params.

And that could apply to primary constructors, too, e.g.:

class Subclass(a: String, b: Int, c: Boolean, d: String, /*...*/ val z: Boolean)
    : Superclass(a, b, c, d, /*...*/)

Right now you have to copy all the parameter names from the superclass (twice), all their types, and all their doc comments. Not very DRY!

I expect others will think of more related cases too.

However, I can’t imagine a syntax which handled all that without being ugly and unwieldy…

1 Like