<https://kotlinlang.slack.com/archives/C0B9K7EP2/p...
# kontributorsr
raulraja
04/17/2019, 9:50 AMi
irus
04/17/2019, 10:50 AMWhy do we need compile-time DI in language, if it's possible with compiler plugins/annotation processing?
p
pakoito
04/17/2019, 11:32 AMAnnotation processing doesn’t work multiplatform, and doesn’t have enough type information to resolve nested/chained dependencies that the compiler does. We tried that approach first and found it wasn’t scalable.
What Dagger does is use annotation processing as an entry point, then scan your files to do the same kind of checking and validation the compiler does. We just removed the extra step and generalised it.
So that discards annotation processors as a red herring. Dagger can do it because it’s a mini-compiler on itself.
pakoito
04/17/2019, 11:33 AMWe’d love for it to be a compiler plugin, and waited for 2 years for them to be publicly available. In communications with Jetbrains we saw that the timelines would not align, and there was no clarity on APIs, so forking was the option we were given at that point.
The work’s done with their help and it’s proven as solid, and 0 cost if you don’t use it. JB has expressed before they’d like to include it into the language, so it seems like an obvious win for everyone that the community did the work 😄
i
irus
04/17/2019, 12:30 PM0 cost for users, but than kotlin team have to support this feature in the language forever. I feel like it shouldn't be part of the language (as spring di shouldn't, obviously), and will rather wait for compiler plugins API.