Hi! We have a new KEEP to share with you — <https:...
# language-proposalss
sandwwraith
03/05/2025, 3:34 PMHi! 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.
😍 4
🚀 3
good idea 2
K 6
g
gildor
10/09/2025, 1:59 AMWhat 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
s
sandwwraith
10/09/2025, 12:27 PMI'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
10/09/2025, 12:28 PMRegarding 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.
r
rnett
10/09/2025, 6:03 PMIs it used in multiplatform androidx libs like compose?
g
gildor
10/10/2025, 3:19 AMandroidx.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
s
sandwwraith
10/13/2025, 8:53 AMbut many multiplatform androidx also have dependency on androidx.annotationCan you name some examples, please? I shall take a look at them
g
gildor
10/13/2025, 8:54 AMgildor
10/13/2025, 8:55 AMcompose 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
s
sandwwraith
10/13/2025, 9:07 AMandroidx.annotation contains a lot of essential annotations, so it doesn't mean that every dependant uses CheckResult
g
gildor
10/13/2025, 9:07 AMyes, 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
10/13/2025, 9:08 AMgildor
10/13/2025, 9:10 AMas 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
4 Views