Im seeing some strange behavior with a CompositionLocal: if my top level composable function accepts...

# compose

[Zoltan Demant]

Im seeing some strange behavior with a CompositionLocal: if my top level composable function accepts a value of X, and defaults to LocalX.current; the value is null, even though it can never be null. If I specify LocalX.current inside the composable I get the proper value. Bug in compose?

[Zoltan Demant]

val LocalStep = compositionLocalOf<Step> {
    throw NullPointerException()
}

@Composable
fun <T> Property(
    modifier: Modifier = Modifier,
    step: Step = LocalStep.current, //crashes
    input: Input<T>,
    onUpdate: (Input<T>) -> Unit,
    label: String? = null,
    style: InputStyle? = null,
    fill: Boolean = false
) {
    val step = LocalStep.current //works
}

[adjpd]

Strange. I use parameters which default to composition local values all the time. So I'm sure it works. I have, however, never issued throw NullPOinterException() as a value of the composition local, so perhaps that's the difference.

[Zoltan Demant]

Same, it works elsewhere for me too. If I specify a different default Step value (instead of throwing); it still crashes.

[Zoltan Demant]

It reminds me of not being able to specify default parameters for composable functions inside interfaces, although Im not sure if theyre related.

[CLOVIS]

You also can't use default parameters inside expect/actual functions

[Zoltan Demant]

This is just a regular function, albeit in a different module than the one its used in, but other functions (even in the same file) work with default parameters.

[theapache64]

@Zoltan Demant I’ve tried accessing compositionLocal from parent scope (using default argument) as well as composable scope. It works for me.

data class User(val name: String)

val LocalUser = compositionLocalOf<User> { throw NullPointerException() }

@Preview
@Composable
fun A() {
    CompositionLocalProvider(LocalUser provides User(name = "Adam")) {
        Column {
            B()
            C()
        }
    }
}

@Composable
fun B(
    user: User = LocalUser.current
) {
    Text(text = "B says user is ${user.name}")
}

@Composable
fun C(){
    val user = LocalUser.current
    Text(text = "C says user is ${user.name}")
}

Can you share a reproducible code like the above?

[Zoltan Demant]

Thanks, my value class was the issue - if you replace data class with value class in your example, it crashes just the same.

@JvmInline
value class User(val name: String)

[Zach Klippenstein (he/him) [MOD]]

@Zoltan Demant It’s not clear from your original message – is your Property function being called from somewhere that LocalStep is actually provided? If so, what’s the exception thrown in the default parameter case?

[theapache64]

@Zoltan Demant I see. I haven’t tried value class with compositionLocal before. I am curious why it didn’t work with the inline class 🤔

[Zoltan Demant]

@Zach Klippenstein (he/him) [MOD]: Yes, its provided and just to verify, I can access it using LocalStep.current before/inside/after the composable function completely fine. I get Parameter specified as non-null is null: method kotlin.jvm.internal.Intrinsics.checkNotNullParameter, parameter step and everything works if I just make it a data class instead of inline. Im using inline classes in other cases, the issue seems to only come up when using them as default values with compositionLocal.current.

[Zach Klippenstein (he/him) [MOD]]

Could you file a bug?

[Zoltan Demant]

Id love to, but today it works. Im on the exact same commit as I was yesterday. I left it as a data class, since that worked last night; and when writing the bug report this morning, I changed it back to a value class just to verify that it was still happening - and now it works. Could it be an issue with the build? What happened yesterday was after a full day of coding. Let me know if theres any more info I can provide!

[Zach Klippenstein (he/him) [MOD]]

Sounds like it could be a caching or daemon issue, yea

[Zach Klippenstein (he/him) [MOD]]

That is probably a bug in itself but prolly much harder to repro