Why does Provides in a Companion Object work?

[dmstocking]

I had a team member put up a review which had a @provides in a companion object and not a module. The example is below. The @Root coroutineScope: CoroutineScope is a TestScope::backgroundScope in case you are wondering what we were trying to do.

@Module
interface TestDeviceCoroutineModule {

    @Binds
    @ComputationCoroutineScope
    @PerDevice
    fun bindsComputationCoroutineScope(@Root coroutineScope: CoroutineScope): CoroutineScope

    @Binds
    @BlockingIoCoroutineScope
    @PerDevice
    fun bindsBlockingIoCoroutineScope(@Root coroutineScope: CoroutineScope): CoroutineScope

    companion object {
        @OptIn(ExperimentalStdlibApi::class)
        @Provides
        @BlockingIoDispatcher
        @PerDevice
        fun providesBlockingIoDispatcher(
            @BlockingIoCoroutineScope coroutineScope: CoroutineScope
        ): CoroutineDispatcher = coroutineScope.coroutineContext[CoroutineDispatcher.Key]!!
    }
}

I was very confused because I couldn't find any documentation saying this should work. I found a ticket or two saying it did and pointing out other problems, but I can't seem to find any documentation or the ticket it was added under. Is this recommended? Should we continue to use the inner class interface Declarations { ... } like in the documentation here https://dagger.dev/dev-guide/faq#why-cant-binds-and-instance-provides-methods-go-in-the-same-module?

[danysantiago]

Using a companion object is a perfectly fine pattern in Kotlin to write a Dagger module that combines @Binds and @Provides declarations. You must realize that the companion object is a different class (an object class) from the enclosing one. In other words you are applying the same pattern as in FAQs page that was written for Java but for Kotlin.

[dmstocking]

Yes a companion object makes a singleton object behind the scenes with your declarations. We all know that. That isn't really the point. I have been using Dagger since literally Dagger1 and there has never in my memory been an instance of an implied module. It is exactly because it is a separate class that is so confusing. I would maybe understand if it instead relied on @JvmStatic, but that isn't even the case here. It also confuses me because it is way less boilerplate than the interface Declarations {. So, why bother documenting the Declarations object way of doing it if an easier solution existed. My only thought is this is somewhat new and undocumented or maybe an accident that people just went with?

[danysantiago]

The solution in the FAQs page is for Java and pre-dates the wide adoption of Kotlin. The support for binding declaration in Kotlin companion objects was added in 2.26. Maybe the action item here is to update the dagger.dev site.

[JakeWharton]

It's separate, sure, but critically it's also associated with the enclosing class. Hence the companion modifier. If you drop that and merely use a nested object this behavior will not work. Traversing the association to discover instance-less (kinda) providers is an ergonomic improvement for Kotlin language support.

[dmstocking]

I am not arguing that it isn't ergonomic. I'm not arguing anything at all lol. I just have never seen this before and couldn't find documentation on it. I didn't know if I changed all my interface Declarations { to companion objects, would this feature break or get removed later.

My understanding now is that this is a feature added in 2.26 that can be used and will not be removed. It is just as good (if not better) than the interface Declarations { and if nothing else a lot shorter to write. Thank you.