I understand what I was asking about should be don...
# reflect
d
I understand what I was asking about should be done through type reification, and allowing a runtime instance to be declared with a type parameter even if just for compile-time checking would be misleading. And that is all fine within Kotlin. I think where it is confusing at first is that it’s allowed in Java, and the pattern of taking a class instance as a parameter of a function doing reflective magic is widespread in Java. You don’t always have control over those frameworks and I wouldn’t have assumed a bridge function would have been necessary to call into them from Kotlin (without casting unsafely). Now that I understand it’s a design choice from Kotlin to be clearer, and an accepted “limitation” (when dealing with Java interop), I get it and I like it, no problem. I just found it a tad confusing, coming from / dealing with java. Thanks @udalov @apatrida for your explanations (there was an exact same thread on youtrack, should have checked first...)