I'm looking at the hilt cheat sheet, and I haven't had to add @Binds to a project yet. What's the use case for it? I have plenty of places in my code where I do:

@Provides
fun provideSomething(
    @ApplicationContext context: Context
): SomethingInterface {
    return SomethingActualImpl(context)
}

it should be a binds

But... it works without binds?

Yes, but binds is more efficient and semantically it is easier to know that a binds is when you are binding an interface with an implementation, and provides for rest.

Binds is better since it is used only at compile time to link implementation to interface. The module itself is not used in Dagger generated code, as dagger would generate the code for linking the two. This means the module class can be fully removed by R8/Proguard on release builds. When provides is used, Dagger generates code that will actually call the method you defined since it can't know what you are doing inside the method.

That's super helpful. Thanks @Arun

@Colton Idle Hope this would help https://sreekumar-av.medium.com/kotlin-dagger-best-practices-966199b48b89

Is there practical difference between

@Binds

and static

@Provides

?

if you are using provides when a binds would work you run the chance of having people basically copy pasting the entire constructor arg list over. That can cause some pretty sad signal to noise ratio's for code reviewers.

I agree.

@Binds

forces dependencies to be public to other modules so sometimes its a tradeoff