narrow type in else block of if (is...)

[@gavinking] Tako gives this example:

shared Integer q(Integer? x) {
    if (is Null x) {
        return 0;
    }
    else {
        return x; //compile error
    }
}

He argues, rather reasonably, that the compiler should be able to reason that x has type Integer where the error occurs.

I agree that it would be possible. This would not amount to supporting types like X~Y, which Ross says results in undecidability, if I recall correctly. It just means being able to utilize the identity X|Y~Y == X, which we already do utilize in certain places.

On the other hand:

1. This example is a bit contrived. It would be much more usual to reverse the condition to do if (is Integer x) or if (exists x).
2. For more complex cases, this is stepping on the turf of the switch statement.

So I’m not sure that this feature would really be especially practically useful. OTOH, it’s easily doable.

[Migrated from ceylon/ceylon-spec#74] [Closed at 2014-11-17 20:31:44]

[CeylonMigrationBot]

[@gavinking] And if, for some irrational reason, you want to use if instead of switch, you can easily write:

value x=getFooOrBar();
if (is Foo x) {
    x.foo();
}
else {
    x.bar();
}

Which is to my eyes much clearer than saying that x is a Foo ooooh except where it’s not.

[CeylonMigrationBot]

[@jvasileff] Oh, cool, this also addresses #4344!