Support injecting top-level functions with context parameters

[alexvanyo]

Description

Right now, injecting a top-level function that has context parameters isn't allowed:

metro/compiler/src/main/kotlin/dev/zacsweers/metro/compiler/fir/checkers/FunctionInjectionChecker.kt

Line 50 in 1cf5ce6

"Injected functions cannot have context parameters.",

It seems reasonable to allow injecting the context parameters, while also allowing assisted injection of the context parameters as well.

Self-contained Reproducer

For a function like the following:

@Inject
@Composable
context(
    @Assisted sharedTransitionScope: SharedTransitionScope
    _: MyUiComponentClass,
)
fun App(
    clock: Clock,
    @Assisted modifier: Modifier = Modifier,
) {
    // ...
}

I would expect to be able to generate something like this:

@Inject
class AppClass(
    private val clock: Clock,
    private val myUiComponentClass: MyUiComponentClass,
) {
    @Composable
    context(sharedTransitionScope: SharedTransitionScope)
    operator fun invoke(
        modifier: Modifier = Modifier,
    ) = lambda(sharedTransitionScope, myUiComponentClass, clock, modifier)

    companion object {
        // Helper lambda to get an invocation of App without `AppClass` in scope
        private val lambda:
            @Composable context(
                SharedTransitionScope,
                MyUiComponentClass
            ) (Clock, Modifier) -> Unit = { clock, modifier ->
                App(clock, modifier)
            }
    }
}

Metro version

0.5.2

Context

With this support, the injected function could then be called like the following, where the AppClass is itself a context parameter:

@Composable
context(
    _: SharedTransitionScope,
    appClass: AppClass,
)
fun AppClass(
    modifier: Modifier = Modifier,
) = appClass(modifier)

Maybe this call-site could this be generated as well?
Or maybe this could optionally be generated if another annotation is present? Maybe that annotation could could help configure visibility?

Function injection as a whole is already opt-in, so maybe there's a more complete story to create there around visibility, overloads, receivers, and other considerations.

[ZacSweers]

I'm game for exploring this, though the fact that function injection requires IDE support to work might make it less useful than we'd like in the near term.

I think we would want to treat all context parameters as implicitly @Assisted right? Or would you envision a scenario where the context parameters themselves are somehow injected? edit: rereading your example, I see you split them

[alexvanyo]

Right, in the example I have one of each for the context parameters, one that is @Assisted and one that is injected. If all of the context parameters are injected, then the resulting method wouldn't need to have any context parameters.

[alexvanyo]

Additional musings about this after setting up context parameter injection manually in my project with metro (more details in https://github.com/alexvanyo/composelife/blob/main/docs/di.md):

I think there's a subtle but useful distinction between injecting a function and injecting a function's context.

When using top-level functions, one of the most useful behaviors about them is that top-level functions are stateless.

When thinking about how to inject a function itself (similar to the top-level function docs of metro does), this distinction is sort of lost. In usage, it "feels" like injecting a top-level function results in needing to call an instance of a function, that theoretically can have independent state. It doesn't need to, of course, but it pulls away from the nice pattern that a top-level function implies.

By injecting the context for a function instead, the lifecycle of the context can be more clear: the context for a function can live independently of whether the function is being called, and the same context can be used to call the function multiple times - this pattern meshes more nicely with top-level function usage that is common in Compose.

In the usage I have set up, there is ultimately a functional type that is injected under the hood, but for maintaining the pattern I like being able to keep the top-level function call-site with an injected context parameter.

Turning this musing into a feature request for the shape of how this may end up being implemented in metro: I think it would be valuable if there is a way for an injected top-level function to be callable via a top-level function. Keeping that matching pattern of what type of function is called feels important to me.