Kotlin language features to embrace

[ZacSweers]

This is a discussion for Kotlin language features to natively embrace. Try to keep threads specific to their topic idea

[ZacSweers]

Support Kotlin's stdlib Lazy - Done ✅

[ZacSweers]

Edit: This is implemented but behind an opt-in flag as generating top-level declarations is not yet supported in incremental compilation. It is also implemented differently. See https://zacsweers.github.io/metro/injection-types/#top-level-function-injection

---

Support top-level function injection. aka support the magic composable function entry point like kotlin-inject supports

typealias Home = @Composable () -> Unit

@Inject
@Composable
fun Home(repo: HomeRepository) {
   // ...
}

@Component
abstract class ApplicationComponent() {
  abstract val home: Home
}

[ZacSweers]

Support optional bindings via default values. This would be an alternative to Dagger's @BindsOptionalOf. Since we are generating IR, we can invoke the defaults constructor/function directly and compute the relevant bitmasks for absent bindings.

Some open questions about this:

• Should there still be some sort of explicit declaration like dagger does?

[ZacSweers]

I personally think we should use the existence of a default parameter value as the implicit opt-in

[ZacSweers]

Implicitly create component factory types when none are defined? Can save boilerplate, but relies a lot on FIR magic + IDE integration.

[japplin]

Something I've been thinking of for improvements to a function injection api would be automatically generating typealiases for functions annotated with @Inject using FIR. Ideally the development experience would mean that a user can start to use a function's exact name and import as a "reference" to the function as soon as they add the @Inject annotation to a function.

An additional improvement to this api is allowing users to bind a specific typealias to a function, while it's not possible to reference a typealias in the properties of building an annotation the way @ContributesBindnig(boundType = MyClass::class) does, it is possible to reference a typealias via a type parameter on the annotation. Putting both of these together we would get this api:

@Inject <-- Automatically generates: typealias MyAutoAlias = () -> Int
fun MyAutoAlias(): Int

typealias MyManualAlias = (MyAutoAlias) -> String
@BindAlias<MyManualAlias>
fun MyManualFunctionWithADifferentName(myAutoAlias: MyAutoAlias): String

@Component
interface ApplicationComponent {
  abstract val myAutoAlias: MyAutoAlias
  abstract val myManualAlias: MyManualAlias
}

[ZacSweers]

Considering Metro's function injection already generates a top-level class class that can be used, what value would this add? Also see the existing thread about this topic above: #22 (comment)

[japplin]

Oh I hadn't seen that section, the top level generated classes look very cool. Is ContributesBinding compatible with function injection?

[ZacSweers]

I'm not sure how it could be given that there's no supertypes involved. Can you elaborate?

[hrach]

Personally, I would use the simple case without parametrization, i.e. a single annotation as a shortcut to add multiple others. Typically for things like ContributeIntoMap - aka custom @ViewModel annotation.

[gildor]

Typealiases do not work as implicit qualifiers, according to the doc, and I'm good with this.

But what about explicit typealias qualifiers? Could this be supported:

@Qualifier
typealias UserId = String

[ZacSweers]

I'm fairly reluctant to treat typealiases different from their aliased type on the graph when value classes are available

[gildor]

It's a good point, but I also feel that use value class instead of qualifier is just worse in terms of UX/API.

Probably String in our practice not even the most common case, but things like Flow etc.

I just comparing:

@Qualifier
typealias SearchQueries = Flow<String>

@Module
class MyModule {
  @Provides
  fun provideSearchQueries(...): SearchQueries = ...
}


// usage:
class MyViewModel(search: SearchQuaries)

vs

@Module
class MyModule {
  @Provides
   @Named("SearchQueries")
  fun provideSearchQueries(...): Flow<String> = ...
}

class MyViewModel(@Named("SearchQueries") search: Flow<String>)

Using value class is also on option, but it would mean also that it require inventing property name and all usages also require code changes

value class SearchQuaries(val flow: Flow<String>)

@Module
class MyModule {
  @Provides
   @Named("SearchQueries")
  fun provideSearchQueries(...): Flow<String> = SearchQuaries(...)
}

// and every usage becomes:
search.flow.collect()
// instead of
search.collect()

I'm not so worry about declaration part, but I prefer more clear API on classes which inject and use, because it potentially used in many places. So no @Named() or other annotation qualifiers on top of actual type and no unnecessary nesting caused by value classes

[ZacSweers]

Your use case in that scenario seems to be to just offer aliases over generic types, but this runs into another issue. What do you do in this case?

@Named("SearchQuery")
@Inject
class SearchQuery<T>

@Named("StringSearchQuery")
typealias StringSearchQuery = SearchQuery<String>

I'm reluctant to allow qualifiers on middleware types because it breaks the principle of least surprise