saveourtool / diktat

Strict coding standard for Kotlin and a custom set of rules for detecting code smells, code style issues and bugs
https://diktat.saveourtool.com
MIT License
537 stars 39 forks source link

Unused arguments in lambda should not have types #1172

Open orchestr7 opened 2 years ago

orchestr7 commented 2 years ago

This is a great stylistic bug, that is not handled by IDEA:

foo {_, _: Int, a: Int - > println("hi") }

diktat should detect and remove a type of such anonymous arguments (_: Int)

This should also be added to the code style

petertrr commented 2 years ago

What if there are several overloads of function foo with the same number of arguments but different types? Then type of the lambda would be ambiguous. I guess it would make sense for named arguments, because I can't imagine a case, when its type cannot be inferred correctly.

orchestr7 commented 2 years ago

I guess it would make sense for named arguments

I meant only unnamed arguments

petertrr commented 2 years ago

I meant some weird corner cases like

fun <T> foo(f: (a: T, b: String) -> Unit) = Unit
fun bar() {
    foo { _: Int, s -> println(s) }
}

Here removing : Int will cause compilation failure

ephemient commented 2 years ago

To give another example on built-in stdlib functions,

list.fold(null) { _: Any?, _ -> }

will not type-check if _: Any? is replaced by _.

orchestr7 commented 2 years ago

Hm, yes, that's true @petertrr @ephemient. But we need to cover at least simple cases somehow...

ephemient commented 2 years ago

Without full type inference it is not possible to determine whether removing the explicit type keeps the same behavior of code or not.