Hello, when writing an inline fun <reified T>...
# language-proposalsg
galex
11/23/2017, 5:52 AMHello, when writing an inline fun <reified T> like the following:
inline fun <reified T> logd(message: String) {
if (BuildConfig.DEBUG) {
Log.d(T::class.java.simpleName, message)
}
}If used without a specified type, the compiler will complain:
To fix this we need to specify the type:logd("abandonAudioFocus() called") // type inference failed: Not enough information to infer parameter T in (...). Please specify explicitly.
Wouldn’t it be convenient if the compiler would infer the type of the class this code is called in in this case? Maybe with a new inline keyword ?logd<PlayerManager>("abandonAudioFocus() called")
g
gildor
11/23/2017, 6:05 AMYou can convert logd to extension function for type T, if you want to have context
gildor
11/23/2017, 6:06 AM Copy code
inline fun <reified T> T.logd(message: String) {
if (BuildConfig.DEBUG) {
Log.d(T::class.java.simpleName, message)
}
}
class PlayerManager {
fun doSmth() {
logd("Log!")
}
}gildor
11/23/2017, 6:07 AMBut such solution pollutes autocomplete
gildor
11/23/2017, 6:09 AMgildor
11/23/2017, 6:11 AMAnd I don’t think that your proposal is good, because it’s too implicit, for example if you use reified type to pass class instance (useful for DSLs and some other cases) and you forgot to pass it you will get parent class instead
g
galex
11/23/2017, 6:15 AMIn your example I see that T is not used so it’s the same as writing this:
galex
11/23/2017, 6:15 AMfun <T: Any> T.logd(message: String) {
if (BuildConfig.DEBUG) {
Log.d(this.javaClass.simpleName, message)
}
}
galex
11/23/2017, 6:17 AMYou are right, it would be really confusing if it was that implicit, that’s why I was thinking about another keyword that could indicate it would be implicit?
g
gildor
11/23/2017, 6:18 AMYes, you right, I don’t need reified there, so even better than solution with reified
g
galex
11/23/2017, 6:27 AMYes indeed