Am i wrong to expect this to compile? ``` sealed ...

# announcements

[arekolek]

Am i wrong to expect this to compile?

sealed class Item {
    data class Foo(val id: Int) : Item()
    object Bar : Item()
}

fun List<Item>.trim() = dropLastWhile { it is Item.Bar || it.id == IGNORED_ID }

It works if I do it !is Item.Foo || it.id == IGNORED_ID though, which is understandable

[diesieben07]

Yes, you are wrong. The smart cast is not that smart.

[arekolek]

I mean in principle, it could be that smart?

[diesieben07]

In principle, yes. However:
It follows Kotlin's idea of code being obvious and clear to understand. You check for a type: That type is smart-casted to. What you "propose" is some "spooky action at a distance", where smart casts behave differently in some situations

[marstran]

I think the reason is that if it !is Item.Foo is false, then it must be Item.Foo. Even if you would later add another subclass to Item.

If it is Item.Bar is false however, then it can be any other subclass of Item. The smart cast would break if you added a new subclass to Item.

[marstran]

So, the smart casting algorithm has no special case for a sealed class with exactly 2 subclasses.

[diesieben07]

Yes. Like I said, it only smart-casts to the types you explicitly check for.

[diesieben07]

In your case Item.Foo is the only type mentioned in your type check, so it's the only type that can be smart-casted to

[wbertan]

I helps, a little, when looking into the decompiled bytecode:
For it !is Item.Foo || it.id == 999

if (it instanceof PathTest.Item.Foo && ((PathTest.Item.Foo)it).getId() != 999) { ... }

In my guess, the way it "optimizes" it, allows the smart cast to be in place and do the second check.
While the it is Item.Bar || it.id == IGNORED_ID will probably "optimize" in a way it cannot "smart" cast to the second expression as it probably didn't rule out the type.
Tweaking a little your example to:

sealed class Item(val name: String) {
        data class Foo(val id: Int) : Item("foo")
        object Bar : Item("bar")
    }

and making it is Item.Bar || it.name == "other" it will compile and generate:

if (!(it instanceof PathTest.Item.Bar) && !Intrinsics.areEqual(it.getName(), "other")) {...}

So we can see how it "optimizes" the first expression, while the one where it "works" it checks if it is an instaceof Item.Foo, this being true will check the second expression knowing the instance is a Foo. In this second example it simply check if isn't Bar, and when reaching the second expression what it knows is the class isn't a Bar but could be anything else (not exactly a Foo).