If you had this, an easy way to convert a property into an object, I'm not sure specifically how but I'm pretty sure a number of your implementations using reflection go away

you can do this now in a non-elegant fashion with a bit of leg work:

val delegate: Delegate = delegate<SomeClass>({ instance.prop }, { it -> instant.prop = it })

with this object its easy enough for you to implement your copy method, I would imagine:

class Delegate<THost, TProp> {
  //...

  fun copyFrom(obj: THost, newVal: TProp): THost = obj...
}

No I suppose it isnt it THost is immutable...

@groostav: to make sure I understand correctly,

delegate

would then be an object you could delegate another property to?

val delegatedProp: Int by delegate

?

sounds exactly like a bound reference:

val boundPropertyRef = instance::prop

,

val delegatedProperty by boundPropertyRef

I proposed that too some time ago. So +1 from me!

But calls on instances of reified type parameters in inline extension functions are not dispatched correctly (I made [a proposal][https://github.com/Kotlin/KEEP/pull/35] for this and a [bug report][https://youtrack.jetbrains.com/issue/KT-12897]), and you cannot create recursive inline functions. So I think the request for implicit

Class

param are valid, aren’t they? For Java compatibility this method could be overloaded by default and then the method with

Class

parameter is called with the upper bound. Of course, this would happen if you add the

reified

keyword...

Note that a

Class<T>

instance represents a class, not a type, so it's not enough to support

as T

and

is T

inside non-inline functions. For example, there's no way to encode if the type passed at the call site was nullable or not in the

Class<T>

instance https://kotlinlang.slack.com/archives/language-proposals/p1470350921000377

It means we should pass something more than just a

Class<T>

.

I wish there was a way of caching a field for an instance in an extension method

put a

WeakHashMap<Object, T>

in a singleton

Now thats an idea

I really appreciate that Android `View`s have

getTag(Int)

and

setTag(Int, Any?)

for that kind of thing

Sure, a

Class<T>

represents the raw type of

T

not the paramaterized type. But more is not necessary to do

is T

because you can use

assignableFrom()

. You can create new instances via the class object, too. Do you mean whether it is an optional type or not with nullable information is ? This information would be already available in the method signature. So the hard one is

as T

(which by the way does not work as expected regarding dispatching in inline functions either see https://github.com/Kotlin/KEEP/pull/35). Copying the function (instead of inlining) would solve this issue, but I do not have a good solution for the implicit parameter variant… I have to think about this 😉

Follow-up regarding

as T

(implicit class parameter for reified generics): This can be done using

Class<T>#cast(Object)

. Since the compiler of Kotlin can check whether this is used appropriately it should be safe (as all safety in Generics world depends on the Compiler in JVM). I would like to write a proposal for that in KEEP … opinions?

@juangamnik: What @udalov says, is that

null is T

expression is true, when T is substituted with

String?

and is false when T is substituted with

String

.

Class<T>

doesn't contain information whether T is nullable or not.

@ilya.gorbunov Ok. Did not know that

T

can be substituted with an optional type. I thought you have to use

T?

then. I don't know whether it is a good idea to replace

T

with some

T'?

with

T': T

because then the code expects instances of

T

not to be

null

, so that

t.foo()

would be Ok for the compiler (declaration-site) although it may be an NPE... I will test this with Kotlin 1.0.3 🤓. But if it is ok for the compiler, a corresponding implicit Boolean flag parameter could be used...

I have an opposite proposal. Instead of making a non-inline overload with

Class<T>

parameter for inline reified overloads, do vice-versa: allow to omit

Class<T>

argument when T is available at compile time. Here is the details https://youtrack.jetbrains.com/issue/KT-10399

Perhaps we have a little misunderstanding what my proposal is about. I do not propose to create a non-inline overload with

Class<T>

parameter for an inline method that has a reified type parameter, but a non-inline method which is „annotated“ with the modifier

reified

and uses the type

T

as if it were an inline method with reified type parameter. Kotlin will generate this to a method with an implicit

Class<T>

parameter (which is not visible in Kotlin) and iff

T

has no upper bound at all a boolean flag is added which says whether the reified type is an optional/nullable or not (this seems to be a special case for

T

without any bound that I wasn’t aware of. This works because an optional has default implementations for

toString()

and co., so that it works as expected even if a null is passed). The Kotlin compiler will/would add an overload to this function without the implicit parameter (a non-inline function), which can be called from Java. It passes the raw type of the upper bound as

cls

(and true for the nullable flag) parameter. It’s just to have a nice Java API without exposing the implicit

cls

parameter. So in Kotlin it would look like this (not a very meaningful example):

fun <reified T> foo(): T? {
  val str = „Hello“
  if (str is T) {
    return str
  }
  else {
    return null
  }
}

fun test() {
  val myStr: String? = foo()
}

So this should print out

Hello

. Let me show the byte code implementation the Kotlin compiler should compile from this, but since IMHO byte code is not so readable I will use semantically equivalent Kotlin code:

// for Java
@Suppress("UNCHECKED_CAST")
fun <T> foo(): T? {
    return foo(cls = Any::class.java, nullable = true) as T
}

// the nullable is only necessary iff there is no upper bound
fun <T> foo(cls: Class<T>, nullable: Boolean): T? {
    val str = "Hello"
    // a nullable check is unnecessary, because `str` can never be `null`
    if(cls.isAssignableFrom(str.javaClass)) {
        return cls.cast(str)
    }
    else {
        return null
    }
}

fun main(args: Array<String>) {
    // This is how it is called from "compiled Kotlin".
    val myStr: String? = foo(cls = String::class.java, nullable = false)
    // This is how Java would call it...
    val myStr2: Any? = foo()
    println(myStr)
    println(myStr2)
}

So with my proposal Kotlins compiler can check what you are doing with the reified type, which is not possible if you pass the class object as a default parameter, because then you are doing reflection in Kotlin instead of let Kotlins compiler check and handle this.

@juangamnik: unfortunately, that boolean parameter spoils the interface. Nullable types for now are only a Kotlin-specific thing and nobody wants to see such a flag in Java. We better find another way to encode this information.

@dstarcev: we could annotate the method with

@Nullable

and use reflection inside?

That was my first thought too. I am not sure if we can get the annotations of the current executing method without affecting performance

Suggested approaches look tricky http://stackoverflow.com/questions/442747/getting-the-name-of-the-current-executing-method

Class<>

is defined final, so we can’t inherit

Sorry,

@Nullable

is static information and therefore won't help. But the Java method doesn't have this parameter. Is it so bad to have an additional method with this parameter for the special case of a

T

without upper bound?

Maybe no. It’s a subjective thing. I would prefer not to expose low-level details to public API

@dstarcev: Another possibility would be to use

java.lang.reflect.Type

or alike in the interface and for the Java version

Class<T>

is passed (which implicitly means

nullable == true

) and the Kotlin compiled code uses

NullableClass<T>

(a newly implemented class) which implements

Type

and delegates to an internal

Class<T>

and adds the information we need.

It would be possible if

Class<T>

weren’t final

I’m sorry, got you wrong

If we expect

Type

to be passed the abstraction will be leaky