Howdy! Can anyone help me explaining why is this h...

# android

[Vladimir Tagakov]

Howdy! Can anyone help me explaining why is this happening:

fun fact(): Observable<Any> = Observable.just(false)
        .distinctUntilChanged() // fails compilation

vs

fun fact(): Observable<Any> = Observable.just(false)
        //.distinctUntilChanged() // compiles just fine

[xxfast]

i think this is due to java’s type erasure

[xxfast]

also 😶

[pepos]

right, same happens in Java version:

Observable<Object> observable = Observable.just(true).distinctUntilChanged(); // does not compile

[pepos]

Observable<Object> observable = Observable.just(true); // compiles just fine

[mkrussel]

It's not type erasure but having a more limited variance model.

Observable is not declared as Observable<out T> since that is not possible with Java. So Kotlin assumes that you can push things into the Observable.

With type inference happening fun fact(): Observable<Any> = Observable.just(false) gets translated to fun fact(): Observable<Any> = Observable.just<Any>(false) since false is an any.

But that doesn't work once you call a method on it. Same thing happens with something like emptyList() the type will be based on what it is getting assigned to, but if you do emptyList().toSet() it will lose the ability to figure out the type and require you to specify it.

[gildor]

Why is it 😶 ? looks perfectly Kotlin for me

And yes, it’s not related on type erasure, mkrussel is right

[ephemient]

right. Kotlin's type inference does more than Java's, but still does not infer through `.`; in general, that's difficult to do in an object-oriented language (ocaml has limitations around too)

[xxfast]

Sorry i thought i was reading rxjava

[xxfast]

yeah given the java code - i dont think this is type erasure as well - looks like limtation with template variance

[Vladimir Tagakov]

@mkrussel ❤️