¿Cómo pasar un parámetro de tipo a una reference genérica de constructor de class?

Supongamos el siguiente código:

class ConstructMe<T> {} data class Test<T> constructor(var supplier: () -> ConstructMe<T>) {} fun main(args: Array<String>) { works<Int>() breaks<Int>() } fun <T> works() { Test<T>({ ConstructMe<T>() }) // (1) any one class type parameter can be removed like: Test({ ConstructMe<T>() }) // (2) still works (class type infernetworking by argument type) Test<T>({ ConstructMe() }) // (3) still works (argument type infernetworking by class type) } fun <T> breaks() { Test<T>(::ConstructMe) // type interference failed (should probably work like (3); compiler improvement possible?) Test<T>(::ConstructMe<T>) // type interference failed & type argument not allowed (language change necessary?) } 

Me he encontrado con esto al pasar las properties JavaFX ( SimpleIntegerProperty , SimpleStringProperty , … y SimpleObjectProperty<T> ) a un argumento genérico de constructores de class () -> Property<T> , donde passing ::SimpleIntegerProperty funciona sin problemas, mientras que ::SimpleObjectProperty falla como el código de ejemplo anterior.

¿Es posible mejorar el comstackdor aquí o permitir el paso de parameters de tipo a references de constructor / function? ¿Tiene sentido usar references de constructor sobre expresiones lambda simples aquí? ¿Comstack de manera diferente?

Sí, es posible mejorar el comstackdor aquí. Podría inferir el parámetro de tipo para ConstructMe . Ver el problema https://youtrack.jetbrains.com/issue/KT-10711 .

Para la function de ounter no en línea (en este caso es el constructor de Test) no hay diferencia entre lambda y la reference invocable al constructor. Para ambos casos, el comstackdor crea una class anónima que tiene un método de invoke que crea una instancia de ConstructMe .

Pero la reference invocable es más conveniente que lambda en los casos en que el constructor tiene muchos parameters.