Why can not type of function parameters with default value be omited?


#1
fun foo(a = "") { // this is invalid
    var b = ""    // while this is ok
}

Is there any reason?


Overload-ambiguity lambda parametercount
Type inference for arguments with default values?
#2

The main reason is compilation performance. When we look at a method call, it helps a lot to have explicit parameter types which don’t need to be inferred. Inferring the parameter type from a string constant is trivial, but if you have fun foo(a = bar()) and bar() also has an inferred return type, understanding the actual parameter type of a becomes very expensive.


Type inference for constructor parameters with default values
#3

Is it somehow different from the inferred return type of the function?


#4

I guess the benefit would overcome the cost. I understand the return type of function needs be declared explicitly because the code flow in function body may be complex. But the inference process of parameter type needs one more step at most, And most of the types is primitive.


#5

Pay attention to function overload: you cannot define variable b multiple times (in the same block) but you can overload function foo using different count/type parameters.

So change the bar return type can modify the invocation graph.
Function pararemter type is important as the return type, in my opinion write it explicitly is part of documentation.
Infert parameter type in some case is a trivial enhancement, harder to justify.

Why 3.toLong() is good but 3.toBigInteger() is bad?
Kotlin doesn’t have the concept of primitive type.


#6

A half-way house on this would be to only allow a parameter’s type to be omitted if it’s default value were a constant expession. In other words the compiler would use the same rule as for ‘const val’ to determine the type which it should be able to do quickly and easily.

This would deal with many cases (often the default value is just a literal) and make function definitions shorter.

Although it could still be used for overloaded functions, it would probably be better to specify the type in such cases in the interests of readability.


#7

I think that it is unnecessary and potentially harmful syntactic sugar. An example: consider we have a default parameter with type Double and it’s default value is zero. We write fun theFunction(par = 0){...}. It produces an error since 0 is in fact integer literal, not floating point. This is obviously a programmers mistake, but one that is very easy to make. In proposed solution it could only be caught in runtime.

Also I personally think that adding complicated behaviors (in this context it works like this, but in other one like that) is a very bad idea.The rules about how language works should be as simple as possible otherwise nobody could remember them (the same as in traffic laws). Do not turn Kotlin into Scala!


#8

I don’t see how that’s any worse than what we can do already with ‘val’ variables which is essentially what parameters are.

In any case I wasn’t suggesting that omitting the type in these circumstances should be compulsory, merely optional. If you’re a library writer, then you’d probably want to specify the type even if it was obvious from the default value.

As the rule for an acceptable default value would be the same as for ‘const val’ it would be easy to remember.


#9

The request to omit the type of optional parameters is tracked here: https://youtrack.jetbrains.com/issue/KT-2801


#10

I’d love to see something similar for class declaration, e.g.:

data class TodoItem(val id = 0L, val body = "", val completed = false)