```fun RequestInit(request: Request): RequestInit ...

# eap

[Marc Knaup]

fun RequestInit(request: Request): RequestInit =
	Object.assign(jsObject(), request)

Why does that work in Kotlin 1.4 but fails in 1.5.0-RC? Is that intentional?

[TYPE_MISMATCH] Type mismatch.

Required: RequestInit

Found: Request

[turansky]

It looks intentional.
AFAIK Promise.then contract fix require such behaviour

[bashor]

how and where assign is defined?

[Marc Knaup]

kotlin-extensions library 1.0.1-pre.148-kotlin-1.4.30

fun <T : Any, R : T> assign(dest: R, vararg src: T?): R

[bashor]

Self contained example, doesn’t work since 1.5.0-M2:

fun <T : Any, R : T> myassign(dest: R, vararg src: T?): R = TODO()

fun <T : Any> myjsObject(): T = TODO()

fun RequestInit(request: Request): RequestInit = myassign(myjsObject(), request)

[bashor]

@Victor Petukhov please take a look

[Victor Petukhov]

@Marc Knaup thanks for the report.

The problem is the same as here. Such code is actually incorrect because for this example:

class Request
class RequestInit

fun <T : Any, R : T> myassign(dest: R, vararg src: T?): R = TODO()

fun <T : Any> myjsObject(): T = TODO()

fun RequestInit(request: Request): RequestInit = myassign(myjsObject(), request)

expected type (RequestInit) isn’t actually subtype of Request as should be by looking at declarations.

Also it can be exploited to go though type system hole and get runtime exception without any compile time errors:

class Request(var x: Int)
class RequestInit {
    fun isRequestInit() {}
}

fun <T, R : T> myassign(dest: R, src: T): R = dest

inline fun <reified T : Request> myjsObject(): T = T::class.createInstance()

fun getRequestInit(request: Request): RequestInit = myassign(myjsObject(), request) // `myjsObject()` has `{Request & RequestInit}` type

fun main() {
    getRequestInit(Request(1)).isRequestInit() // CCE: java.lang.Object cannot be cast to Request
}

So the change in the compiler is intended (it was really introduced recently), and source code’s fix is needed.

[Marc Knaup]

Interesting. Does that mean that the definition of assign is incorrect? I don’t understand the reason for the R : T constraint anyway.

[Victor Petukhov]

You have two ways to fix it: change `assign`’s declaration by removing R : T or change use site – actual arguments by passing only arguments which satisfy to upper bound constraint.

[Marc Knaup]

Well solution #1 is up for JetBrains to fix – if that doesn’t cause other issues.

I’ve done #2 like this:

fun RequestInit(request: Request): RequestInit =
	Object.assign(jsObject<RequestInit>(), request)

[Marc Knaup]

Thanks for the feedback and explanation 🙏

[Victor Petukhov]

BTW during investigation affected area by this fix in the compiler, we’ve discovered pretty similar issue in the Corda source code: https://github.com/corda/corda/issues/6888

[Marc Knaup]

No idea what that is though 🙂
But yeah, +1 on improving type safety.

[bashor]

It looks like it couldn’t express in Kotlin more precise than

fun <D, R : D> assign(dest: D, vararg src: Any?): R

[bashor]

cc @Akif Abasov [JB] @Leonid Khachaturov

[turansky]

Or dynamic sources?

fun <D, R : D> assign(dest: D, vararg src: dynamic): R

[Leonid Khachaturov]

Please create a PR in https://github.com/JetBrains/kotlin-wrappers