Now I’m deeply confused how modifier chaining and kotlin in general works :thinking_face: There is ...

# compose

[Paul Woitaschek]

Now I’m deeply confused how modifier chaining and kotlin in general works 🤔

There is a new lint:
https://googlesamples.github.io/android-custom-lint-rules/checks/ModifierFactoryUnreferencedReceiver.md.html

And it says that here the original modifier is unused:

private fun Modifier.unicorns() : Modifier = background(Color.Red)

But is it really?

[sindrenm]

I had this warning some time ago, but it disappeared again. It seems like a bug to me.

background(Color.Red) is just this.background(Color.Red), which does indeed reference the original modifier (this).

[Paul Woitaschek]

It’s very weird

[sindrenm]

The warning is probably to warn you if you were to do something like this:

private fun Modifier.unicorns() : Modifier = Modifier.background(Color.Red)

[Paul Woitaschek]

Yeah that makes absolute sense

[sindrenm]

I'm pretty sure it's a bug in the lint check.

[Paul Woitaschek]

Yeah me too. Just wondered if there was something fundamentally I don’t understand

[sindrenm]

It could be related to this one, perhaps? https://issuetracker.google.com/issues/187539461

[Hristijan]

You can use .then(//something modifierish)

[Paul Woitaschek]

Yes that’s what its saying. The question is: Is it necessary

[Hristijan]

.then does strict equality check if the modifier is the same otherwise it combines the one that's a receiver and the parameter one, I think that might be an optimization in place that they want us to use

[eygraber]

Possibly related

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1700695658396079?thread_ts=1700687932.814509&cid=CJLTWPH7S

[efemoney]

Its a lint bug.