I just ran into a seeming shortcoming in the type inference system, can't find any tickets on youtrack, has anyone else run in to this?

// both Foo and Bar extend Item
val item: Any? = getSomething()
if(item is Foo || item is Bar) {
  // I would expect this to smart cast to Item -- defining Item as a sealed class doesn't seem to help either
  doThingWithItem(item) //Error - Type mismatch, required: Item, found Any?
}

That's not how smart casts work. Smart casts will only cast to types you explicitly checked for.

also, why not just check if

item is Item

?

Because I believe there are cases where I don't want to call

doThingWithItem()

with any Item subclass (I'm actually going to check though-- this line came about during a Java -> Kotlin conversion).

@dalexander Could you elaborate on that?

if(item is Foo || item is Bar)

is type checking. Do you mean you don't like casting if you can avoid it?

Yeah, definitely there are kinds of

Items

that should be excluded from that call.

The reason this doesn't work is to prevent "spooky action at a distance" situations. If you were to add additional subclasses of

Item

suddenly your smart-cast no longer compiles (even worse, it's in a seperately compiled library and is now incorrect!)

If you add additional sublasses, still Foo and Bar respond to Item, where is the problem?

That's not true. Adding new subclasses of

Item

doesn't mean if something is a

Foo

or

Bar

that it is also no longer an

Item

.

Yes I misspoke there, what I described was a different situation. However there are still situations where this breaks (e.g. the superclass is changed)

It seems like it's just a limitation of smart casting, which I think is a fine answer. The follow up question is if the Kotlin teams want to consider this use case.

abstract class Parent
class Child1 : Parent()

fun main() {
    val a: Any? = ""
    if (a is Child1)
        funOnParent(a)
}

fun funOnParent(parent: Parent) = println(parent.javaClass)

This is working for me

Okay, so if I change the if statement to

if(item is Foo) {
        doThingWithItem(item)
    }

it works by the way.

Yes, because then you get a smart-cast to

Foo

.

So basically with more than one the compiler is still unsure on the exact type, even though both are children of

Item

You can't smart-cast to two separate types. Kotlin does not have union types

Right-- presumably because it doesn't have internal representations for this kind of composite type. Which is fine.

mmh. I feel like these should be equivalent no?

if(item is Foo || item is Bar) {
  doThingWithItem(item)
}

if(item is Foo) {
  doThingWithItem(item)
} elseif(item is Bar){
  doThingWithItem(item)
}

and

when(item) {
  is Foo -> doThingWithItem(item)
  is Bar -> doThingWithItem(item)
}

Right, we don't have union types inside the compiler but using common supertype of

Foo

and

Bar

after a check like

item is Foo || item is Bar

for

item

can be a good approximation. I think it can be a nice feature, @dalexander can you please create a YT ticket?

Sure, I can see about putting together a use case and a ticket.