when will SAM conversion will be implemented in Ko...

# announcements

[Olekss]

when will SAM conversion will be implemented in Kotlin? I mean for Kotlin SAM interfaces

[monku]

isn't it already here: https://try.kotlinlang.org/#/Kotlin%20Koans/Introduction/SAM%20conversions/Task.kt ?

[Olekss]

I think they work from Java code, but if you have kotlin Interface it does not work

[Olekss]

My concern is exactly coz if I want SAM interfaces and use the SAM conversions I need to write them in Java, coz if I write them in Kotlin - won't work

[david-wg2]

By the looks of it it's not a priority, the issue has been open for years..

[alex2069]

Unless you need to interact with Java use a typealias

[Andreas Sinz]

@Olekss what advantage does a SAM Interface have over a (T) -> R?

[hho]

@Olekss You don't need them in Kotlin, because Kotlin has proper function types.

[arekolek]

I guess they might be nice on Android, for example if you use data binding, you won't be able to access the lambda type from layout (so it's kind of the "interacting with Java" case, but indirectly).

[david-wg2]

the issue is if you want to create an API that is going to be used from both languages, you can't make it in kotlin.
if you want an interface as a parameter, you need to make the API in java

[Andreas Sinz]

@david-wg2 why do you have to create the API in java? (T) -> R is just a Function<T, R> under the hood and can be used from java just fine

[david-wg2]

but it's not an interface

[Andreas Sinz]

so we are back at the question, what advantages does a SAM-Interface have over a simple (T) -> R?

[david-wg2]

you can implement an interface, you can convey intent in the naming of it (and its method)

[Andreas Sinz]

I wouldn't say implementing an interface is an advantage (Functional types are more flexible, because you don't have to implement anything)

[Andreas Sinz]

and the naming part can be done in kotlin, Interface name will be the typealias and the method-name is the argument-name, but doesn't work in java

[david-wg2]

how is it more flexible if it offers a subset of what the other approach offers?

[david-wg2]

this is a real pain when making an API for both java and kotlin users

[Andreas Sinz]

it is more flexible because everything that has the shape (T) -> R can be used, doesn't matter if its a top-level function, "static" function or an instance method. Using a SAM-Interface, the method/function has to be wrapped inside an anonymous object (lambda) that implements the Interface

[Andreas Sinz]

if you say subset, what is possible with an interface but not with a functional type?

[david-wg2]

i'll have to get back to this after work 😬

[karelpeeters]

@Andreas Sinz Theoretically functional types are better of course, but in practise they make the API difficult to use from Java. The other alternative are SAM interfaces but those are a pain to use from Kotlin.

[Andreas Sinz]

what makes it hard to use from java? isn't (T) -> R just a Function<T, R>?

[tipsy]

@Andreas Sinz https://docs.google.com/document/d/1QGRugXflSrYaEpq9BiEjdz2yojF6Ubqh5gUE3IprNnU/edit?usp=sharing

[louiscad]

Kotlin SAM lambda conversion is expected in Kotlin 1.3. It has the advantages of not having autoboxing when not inline

[Andreas Sinz]

so it should be possible to call a functional type with a lambda in java just fine, right?