Dmitry N. Petrov

No, this is wrong, because it can change the behavior of code in question. As we have discussed it before, it has nothing to do with the sealedness of the...

No. Inline functions are inlined at compile-time. Operations involving reified type parameters are annotated with special bytecode instructions. Bytecode is post-processed at call-site, where corresponding type arguments are known.

Ok, if we don't want to break too much, this is in fact "duck typing for reified parameters". To do it properly, type constraints for reified types should be expressed...

Currently it's all about syntax, which is definitely not enough. Should "dynamic dispatch" work for receivers of `reified` type parameter type only? How exactly should "dynamic dispatch" work? (you can...

Can you describe in detail how the dispatch should be performed? - Can a function (property) with `dispatch` receiver parameter be invoked outside of `inline` function with `reified` type parameters?...

So, it sounds more like an overloaded function resolved at call-site during inlining. I'd rather treat those as regular overloaded functions (no `dispatch` keyword needed, really), but mark those reified...

"Module" in Kotlin is a compilation unit as defined by the build system. It is not "package" (which corresponds to package in JVM). It's not clear to me how "overriding...

Sure, there are some, sorry for a long delay. I need some free cycles to explain my technical concerns in detail.

So far, I find the following issues with this proposal (or maybe with the approach in general): 1. Search scope for extension override resolution is probably too broad. For a...

Ok, so, essentially this boils down to a dispatch table built at execution time. This requires detailed high-level rules expressed in terms of class loading (NB there's no such thing...