Were there changes made to `UnnecessaryLet` for 1.20? I got a lot of violations in my project after...

# detekt

[eygraber]

Were there changes made to UnnecessaryLet for 1.20?

I got a lot of violations in my project after updating to RC2. Most of them are related to using an "out" parameter, but I'm not sure if there's anything detekt can do there, and removing the let isn't terrible.

There are some others, and I got one like this, and I'm not sure why it's unnecessary:

fun View.postHideKeyboard(shouldClearFocus: Boolean = false) {
  if(shouldClearFocus) {
    clearFocus()
  }
  val imm = context.getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager

  rootView.windowToken.let { token -> <http://rootView.post|rootView.post> { imm.hideSoftInputFromWindow(token, 0) } }
}

[eygraber]

Similarly:

fun String.sha256(): String =
  MessageDigest
    .getInstance("SHA-256")
    .also { it.update(toByteArray()) }
    .digest()
    .let { Base64.encodeToString(it, Base64.DEFAULT) }
    .run { substring(0, length - 1) }

This seems a bit aggressive

[mkrussel]

https://github.com/detekt/detekt/issues/4388

[mkrussel]

I think the tool is probably correct about your first example (using let there just makes it more complicated).

The second example I think is a good case for using let outside of null handling.

[eygraber]

For the first example, I like to use let as a scoping function. So if I only wanted token to be used in that scope within that function, I would think the let was OK.

[mkrussel]

Then you probably want to disable the rule. Since that is what it was created to detect.

[eygraber]

I think the rule is useful in many other ways, but this seems more aggressive to me.

[mkrussel]

I am surprised that 1.19 didn't flag those examples.

[eygraber]

Yeah I'm starting to think there was an issue with how I ran detekt with type resolution because I'm getting hundreds of violations now across my project