Omitting same parameter types

Language Design
1

Every time when you are writing functions with a lot of parameters like this

fun rectangle(x1: Int, y1: Int, x2: Int, y2: Int) {
    /** code **/
}

or even like this one:

fun setMatrix(a1: Float, a2: Float, a3: Float, a4: Float, b1: Float, b2: Float, b3: Float, b4: Float, 
              c1: Float, c2: Float, c3: Float, c4: Float, d1: Float, d2: Float, d3: Float, d4: Float) {
    /** code **/
}

It’s getting ridiculous to write every single parameter’s type there.
And to solve this problem I wanna suggest that syntax with omitting parameter types in functions:

fun rectangle(x1, y1, x2, y2: Int) {
    /** code **/
}

fun setMatrix(a1, a2, a3, a4, b1, b2, b3, b4, c1, c2, c3, c4, d1, d2, d3, d4: Float) {
    /** code **/
}

These parameters would be much more readable and preferable for Kotlin language users.

Hope you’ll support this idea

2

If you are using more than 5 parameters, you are probably doing something wrong. Also remember, that there is vararg keyword.

2 Likes
3

No, some math / rendering libraries or functions are using these methods with a lot of parameters. For example, when you are wrapping some functions from OpenGL library you have to write the whole list of parameters. And when you are making some math functions like operations with matrices etc. There are a lot of cases when you need to list all the parameters with the same type, and you can’t replace them with varargs.

1 Like
4

I am doing math libraries :slight_smile:

As for OpenGL, you will have to write a lot of ugly code once to make a wrapper. But only once. No need to change language for that.

1 Like
5

What about configuration classes and builder blocks

DSL builders is the kotlin way of passing configuration

6

I can’t think of much against it but I’d also say i think it only adds value in less common cases.

As @darksnake said, more than three params (without considering name, defaulted, and optional params) is considered a code smell. You’ll still have valid functions with more than three but they should have to pass extra scrutiny.

In Kotlin, named params and defaults can enable slightly more functions with extra params. Also use cases like DSLs lend themselves for more params.

For your specific use case, I’d say a syntax change may help in writing it out. However, before you do that, you should already have the params on their own line. I’d argue that the better readability of params on their own line is more important than saving the keyboard strokes.

The idea isn’t bad but I’d be curious is there are any other cases that support it. While the example use cases do help with the pain of typing it on one line, readability isn’t clearly improved (and arguably worse).

Maybe there’s some IDE live template or shortcuts to help with the pain of typing out params with the same type?

7

Ctrl c, ctrl v. No need to make it harder than it is. :slightly_smiling_face: