while thinking about the KEEP for bound callable refereces, I noticed that the following doesn't work:

class Foo {
    fun Foo.doStuff() {}
}

fun bar() {
    val a = Foo::doStuff
}

I'm not sure if it has any applications, but currently there's no way at all to create a reference to

doStuff

btw, you also can't reference it from within

Foo

. It may make sense to implement this as part of the KEEP.

@udalov: ^^

@kirillrakhman: Can you add it to the KEEP issue?

sure

I already commented on the scenario from within the class

then I noticed that referencing it from outside is even weirder

I don't think this is related to the bound references KEEP in fact

I think it's a bit related. What if I want to create a bound reference to

doStuff

after all? The answer is, I need to bind two receivers instead of one. This leads to the question, wether or not this is a desirable feature and what the syntax for it might be

but you're right in that there is an additional question, i.e. whether we want to be able to create unbound references to instance extension methods

More interesting question is partially bound reference, so in the example

doStuff

above, what if I do

fooInstance::doStuff

and then I could call it with

anotherFooInstance.boundRef()

yes, that's the logical consequence of the two previous questions

@cfleming: org.jetbrains.kotlin.codegen.optimization.boxing https://github.com/JetBrains/kotlin/tree/master/compiler/backend/src/org/jetbrains/kotlin/codegen/optimization/boxing

@dmitry.petrov: Great, thank you.

Is the basic idea that it will convert objects to primitives for a particular method when that method doesn’t use nullable types?

Not exactly. We use reaching definitions analysis (on bytecode) to keep track of how boxed values are used. If those usages are "good", we eliminate boxing/unboxing and rewrite corresponding operations if required.

For some definition of “good”? simple smile

In general - usage that can be replaced with operation on a primitive type. However, we do not recognize some practically important special cases yet.

Yep, let's move this discussion to #C0BUHC9HD simple smile

Ok, sounds good.

https://kotlinlang.slack.com/archives/general/p1462872296003296 @domfox is asking if we can have

constructorParameterIndex

and direct typed access to

copy

method for data classes via KProperty. /cc @udalov

Where does kotlin stand on union types?

I want to create a union of some of the primative types

e.g.

primative = Int | String | Boolean

there is no way to represent this on the JVM. at runtime this will be boxed in any case, even if Kotlin did provide some support for union types

@jkbbwr: please share your use cases in https://discuss.kotlinlang.org/t/union-types/77

usually I find that I want union types when using callbacks or observables where the responses can be of totally disparate types. manually boxing them in sealed classes works, but could be simplified with a

(String | Int | Boolean) -> Unit

type situation

@damian: what framework requires a callback on three different unrelated types?

@yole: I would hope that language features would be considered regardless of how easily they can be represented on the JVM. While that may be Kotlin’s primary target right now, that might not always be the case, and you even have a JS target in progress. Union types would be incredibly handy to have.