Deprecate support for typealias qualifiers

[rharter]

Using typealiases as disambiguating qualifiers is a stretch of the language feature and doesn't align with the typealias contract. A typealias allows you to use another name for a thing, whereas a qualifier is meant to disambiguate between two different things represented by the same underlying type.

Additionally, the presence of inline classes eliminates the need for any kind of qualifier, since they provide a toll-free way to disambiguate values based on what they represent, rather than their type.

The suggestion here is to deprecate the use of typealiases as qualifiers and instead recommend the use of inline classes (i.e. user defined value classes) for such cases.

[burningfireplace]

I see how you could say that this is a stretch of the original language feature but I don't see how it can cause any harm now or in the future. Inline classes aren't a real typealias replacement because you have to "unpack/unwrap" the inlined type. IMHO: inline classes solve another problem that overlaps sometimes with this use case.

A processor option that throws a warning or error and something like Dagger's qualifier annotations should do the trick for code bases that don't want to use typealias to differentiate between different instances of the same type.

[evant]

Not a fan of a processor option because turning it on or off could have very subtle effects on how types resolve. And qualifiers are already supported behind the javax.inject option though personally not a fan of their lack of type-safety.

[JakeWharton]

I don't see how it can cause any harm now or in the future.

Using the refactoring option to introduce a typealias for a type which participates in the graph is now a breaking change. This is the opposite of how a typealias is meant to work.

[burningfireplace]

Okay, I see now how a newly introduced typealias could break the DI graph. What about annotated typealiases? As far as I understand it after a glimpse at the ksp compiler source and a google search, it should be possible to do something like this:

@Qualifier
typealias Dep1 = Dep

@Qualifier
typealias Dep2 = Dep

@Component
abstract class MyComponent {
    @Provides
    fun dep1(): Dep1 = Dep("one")

    @Provides
    fun dep2(): Dep2 = Dep("two")

    @Provides
    fun provides(dep1: Dep1, dep2: Dep2): Thing = Thing(dep1, dep2)
}

@Inject
class InjectedClass(dep1: Dep1, dep2: Dep2)

[damianw]

IMO: A more natural pattern, which would be consistent with things like kotlinx-serialization, would be to support qualifier annotations directly on types. That would be a bit closer to how Dagger does it too, and allows for more expressive options than solely relying on types or type aliases. You could still use type aliases in that case, the same as they suggest for kotlinx-serialization, but in a way that doesn't abuse the language feature.

For example, I have seen use cases come up where it is more natural to qualify something by a string name rather than by an actual type (e.g. a service with a particular name); that is possible with Dagger (using Named) but not possible here due to lack of support for richer qualifiers (without generating a bespoke typealias or wrapper class as proposed in the OP).

I would propose adding a Qualifier annotation as Dagger has, to be applied to annotation types that themselves apply to types:

@Target(AnnotationTarget.ANNOTATION_CLASS)
annotation class Qualifier

Such qualifiers could be defined as so:

@Qualifier
@Target(AnnotationTarget.TYPE)
annotation class Named(val value: String)

That would then allow for flexibility such as:

data class Dep(val name: String)

typealias Dep1 = @Named("one") Dep

@Component
abstract class MyComponent {

    // Using typealias allows for shorter names like is already possible.
    @Provides
    fun dep1(): Dep1 = Dep("one")

    // Or, the qualifiers can be used inline.
    @Provides
    fun dep2(): @Named("two") Dep = Dep("two")
}

[damianw]

@evant Thoughts on the above? Would you be open to a PR exploring this?

[chrisbanes]

Why do we need typealiases at all? Can we not rely on qualifiers entirely like Dagger?

@Component
abstract class MyComponent {
    @Provides
    @Named("foo")
    fun fooDep(): Dep = Dep(...)
}

[chrisbanes]

We ended up enabling the javax.inject support for this, but as we're building for KMP I had to create a 'fake' javax.inject.Qualifier class.

package javax.inject

annotation class Qualifier

package com.myapp.qualifiers

@javax.inject.Qualifier
annotation class IoCoroutineDispatcher

Seems to be working nicely.

[evant]

Usage note: I've been trying to use value classes in place of typealias on my side project to see how it feels, the downside is that it makes usages sites a bit more verbose and I fell into this pattern:

value class IODispatcher(val value: CoroutineDispatcher)

@Inject class MyRepository(dispatcher: IODispatcher) {
   private val dispatcher = dispatcher.value
}

this may lead credence to including qualifiers to cut down on this. This isn't an argument for one thing or another just thought I'd jot it down.