Hi! We have a new KEEP to share with you — <https://github.com/Kotlin/KEEP/issues/412>. It is about ...

# language-proposals

[sandwwraith]

Hi! We have a new KEEP to share with you — https://github.com/Kotlin/KEEP/issues/412. It is about enhancing the functionality of the existing 'unused expression' static analysis in the Kotlin compiler. New diagnostic should be able to report complex expressions whose return values are meaningful (e.g., non-Unit) but are not used.

[gildor]

What is the current status of "Interop with Java and existing annotations"?

I don't see mentions of this in 2.3.0-beta1 notes

If it's not there, should we start a discussion on the initial list of annotations? Or maybe it could be configurable

For example, there is androidx.annotation.CheckResult, which is not mentioned in the proposal

[sandwwraith]

I'm preparing update for the KEEP with all the recent design advancements, which also includes list for all available annotations. In the meanwhile, you can check this ticket: https://youtrack.jetbrains.com/issue/KT-71244, it should mention. all added commits

[sandwwraith]

Regarding Android's CheckResult in particular, I'm not sure it would be beneficial to add it right away, since annotated declaration would be already reported by Android Lint.

[rnett]

Is it used in multiplatform androidx libs like compose?

[gildor]

androidx.annotation.CheckResult is multiplatform by itself
Not sure specifically about compose, but many multiplatform androidx also have dependency on androidx.annotation

For me the main reason for support of CheckResult, is an early adoption of Unused return value checker feature. So we already could start preparing code for it.
lint is not the same as a compiler error after all. Lint is not run on every check. Though, yeah, it has IDE reports too.

Maybe eventually migrate to MustUseReturnValues, but now have CheckResult as an alias for MustUseReturnValues looks as the best solution which doesn't require code changes and already allows to test new compiler feature

[sandwwraith]

but many multiplatform androidx also have dependency on androidx.annotation

Can you name some examples, please? I shall take a look at them

[gildor]

https://mvnrepository.com/artifact/androidx.annotation/annotation/usages

[gildor]

compose us uses it, just as an example

But as I said, I don't know if there are ones, which use CheckResult specifically

And usage in androidx. is not my main concern to be honest, But concidering that there are almost 6500 artifacts which depend on androidx.annotation, probably quite a few may use CheckResult

[sandwwraith]

androidx.annotation contains a lot of essential annotations, so it doesn't mean that every dependant uses CheckResult

[gildor]

yes, I'm not arguing with it
My point is that it's very popular library, as result it's version of CheckResult is very popular too, at least on app level

[gildor]

https://github.com/search?q=%22import+androidx.annotation.CheckResult%22&amp;type=code

[gildor]

as I already mentioned, I'm coming purely from application adoption point of view, because we depend on androidx.annotation, CheckResult is already annotation of choice for all our use cases