Is there a reason `operator fun getValue` needs to take a `KProperty<*>`, and can't take a mor...

# language-evolution

[Ben Woodworth]

Is there a reason operator fun getValue needs to take a KProperty<*>, and can't take a more specific property type? (and same for setValue)

And similarly, is it always safe to cast property to a KProperty of the return type (assuming it's called as a delegate, and not directly), e.g.

operator fun Foo.getValue(thisRef: Any?, property: KProperty<*>): String {
    @Suppress("UNCHECKED_CAST")
    val stringProperty = property as KProperty<String>

    // ...
}

[Ben Woodworth]

The only thing I can think of is to simplify overload resolution, or just as a way to outright disallow delegation overloads.

Unless there's a type argument variance case I'm not thinking of. But that's what I'm getting at with the second part of the question

[Wout Werkman]

The property could technically be a supertype

fun main() {
    val anyField: Any by Foo("foo")
    println(anyField) // kotlin.Any
}

class Foo(val a: String)
operator fun Foo.getValue(self: Any?, property: KProperty<*>): String {
    return property.returnType.toString()
}

Even though semantically, yes. I can not imagine a scenario where it breaks your expectation.