for example: ```fun fnTakingUnitLambda(fn: ()->Uni...

# compiler

[Jakob Heher]

for example:

fun fnTakingUnitLambda(fn: ()->Unit) = ...

// this is legal, and i want it not to be:
fnTakingUnitLambda { 42 }

// this should still be legal:
fnTakingUnitLambda { Unit }

// this should also work:
fnTakingUnitLambda { someOtherFnThatReturnsUnit() }

[Youssef Shoaib [MOD]]

The new return value checker will warn on this!

[Jakob Heher]

ah, something like that was my intuition too, that's good; my actual use case is this (IMO rather pathological) behavior of `Result::map`: https://pl.kotl.in/zGaiZ1DR5

this makes Result<Unit>-returning functions extremely misuse-prone, since simply using the "wrong" map function (map instead of transform) will cause the error to be quietly swallowed

[Youssef Shoaib [MOD]]

There's another option specifically for this case. There's an internal annotation @OnlyInputTypes that forces the compiler to ignore info from expected types. You can access them by redefining them in your own code, or with some error suppressions (but that's unrecommended)

[Youssef Shoaib [MOD]]

But the real solution is definitely the return value checker, since that specifically addresses the Unit issue

[Jakob Heher]

i tried annotating map with @OnlyInputTypes and the code above still compiles, strangely enough

[Jakob Heher]

https://pl.kotl.in/0x94Rvnpu

[Jakob Heher]

so it seems that T is still coerced to Unit by the return type

[Youssef Shoaib [MOD]]

Weird.
At least @NoInfer works:

@Suppress("INVISIBLE_MEMBER", "INVISIBLE_REFERENCE")
fun <T> fnReturningBlockType(fn: ()->T): @kotlin.internal.NoInfer T = fn()

fun main() {
    val x: Unit = fnReturningBlockType { 42 } // Initializer type mismatch: expected 'kotlin.Unit', actual '<http://kotlin.Int|kotlin.Int>'.
}

[Youssef Shoaib [MOD]]

I wish we had access to these annotations easily, under some experimental opt-in (that mechanism didn't exist back then)

[Jakob Heher]

that does seem to work, excellent

[Jakob Heher]

and since Result has out variance the ignoring should also not cause complications (we'll still test this)

[Jakob Heher]

welp, i'm back on this topic; @NoInfer behaves as expected (it prevents the compiler from using the explicit result type as a hint that it should coerce to Unit) in kotlin 2.1.20

[Jakob Heher]

but in kotlin 2.2.21, this is no longer the case

[Jakob Heher]

MWE for this: https://pl.kotl.in/ytlLKmSj6

[Jakob Heher]

in kotlin 2.0 and kotlin 2.1 this produces the expected Initializer type mismatch

[Jakob Heher]

in kotlin 2.2 this compiles

[Jakob Heher]

https://youtrack.jetbrains.com/issue/KT-82863/NoInfer-regression-from-Kotlin-2.1-to-Kotlin-2.2 created an issue for this