Johannes Neubauer

@abreslav > It is a hard constraint that the language evolves in a backwards-compatible way. This proposal will alter behavior of potentially a lot of existing code silently. We'd need...

@abreslav If I should not drop the proposal 😉 should I rename it to "type-checking of reified types"? Since if you call an instance method on an instance of a...

@ilya-g > > Do you mean this documentation: https://kotlinlang.org/docs/reference/inline-functions.html#reified-type-parameters? Yes. The documentation there says: > We qualified the type parameter with the reified modifier, now it’s accessible inside the function,...

@dnpetrov > Otherwise, as it was said before, functions using duck typing (that is inline functions with reified type parameters) will have to be fully type-checked at call site. IMHO,...

> Should "dynamic dispatch" work for receivers of `reified` type parameter type only? No, for all explicit extension receivers. I thought that the example code already illustrates that, doesn't it?...

> Can you describe in detail how the dispatch should be performed? Yes. I was on vacation I need to find some spare time. I will include this (and the...

No I don't think so. As I wrote in my answer it should work for normal non-inline functions, too. I don't think that this proposal should have anything to do...

OK I think I know now why you mean this is a special form of overload. Consider the following snippet in Kotlin 1.0.3 (sorry it is long): ``` kotlin open...

@dnpetrov I tried out several examples and I agree that adding a keyword `dispatch` for this is not necessary in the first step. I updated/refined the proposal accordingly (and renamed...

@dnpetrov: I added a description regarding the scope (as you asked me) and a section on realization in a translational fashion presenting a possible implementation (what the compiler would output)...