Properly handle nullable/platform types. about kotlin-inject

[evant]

Got a couple of thoughts here, we could either:

1. Be strict like ksp is (I think the metadata is there in the kapt backend to do this)
2. Allow types to be 'upgraded' when compatible. This would be similar to how you can do both foo: Foo = javaMethodThatReturnsFoo() and foo: Foo? = javaMethodThatReturnsFoo() in kotlin.

I'm leaning towards 1 for fewer surprises but it does mean you may have to explicitly declare the return type on a @Provides in some cases. Maybe an explicit warning/error message here could help?

[sunian]

I'd prefer option 1 as well.

[rf43]

I agree with @sunian that as a consumer, option 1 seems to be the safest, most forward looking solution.

Also, may have to explicitly declare the return type on a @Provides in some cases while slightly inconvenient I wouldn't think that's too bad.

[evant]

It's not inconvenient no, but it did take me a bit to figure out what was happening. I had

@Provides fun retrofit(client: OkHttpClient) = Retrofit.Builder().build()
@Provides fun myService(retrofit: Retrofit): MyService = retrofit.create()

and it was complaining that it couldn't find retrofit. Again a targeted warning/error might be good enough though.

[evant]

Fixed so the behavior in both back-ends matched. Keeping this open until we can get a better error for this case.

[evant]

Ended up disallowing platform types in @Provides methods. You get a helpful error telling you to declare the return type explicitly. This not only better documents your intent, but means you if you get it wrong (say fun foo(): Foo = javaMethodThatCanReturnNull() you get a NPE in your code instead of deep in the generated code.