flow sensitive typing for value cases

The following does not compile:

String|Absent foo<Absent=Nothing>
        (Float|Integer|Absent input)
        given Absent satisfies Null
    =>  switch (input)
        case (is Float) "f"
        case (is Integer) "i"
        case (null) input;

// error: specified expression type must be assignable to declared return type:
// 'String|Float|Integer|Absent' is not assignable to 'String|Absent'

Replacing case (null) with else eliminates the error at the expense of readability. case (is Null) also works.

I presume we don’t want to use the type \Inull, but I think subtracting Float and Integer (as is done with else) would be nice here, making input Absent.

[jvasileff]

so I’m not going to be the one that closes this issue 😃

I totally lied. This has been duplicated by #7248. Closing.

[jvasileff]

For object values like null and red | green, the simple alternatives is Null and is \Ired |\Igreen work. In the case of null the alternative is no worse. And for red | green, I know typesafe use of subsets of enumerated cases isn’t common.

I presume we don’t want to use the type \Inull

I’m not entirely sure why I said that. We’d be narrowing, not inferring.

For literal values like case (7 | 13) { processSpecialNum(obj); }, it would be useful for obj to be Integer, but this hasn’t come up in any code I’ve written.

unless someone can show me a truly compelling use-case.

I haven’t been able to convince myself that this feature would be useless, so I’m not going to be the one that closes this issue 😃.