Tagged enum inference with string literal types isn't sophisticated enough

[sophiebits]

Ideally this would type-check

/* @flow */

type T =
    {type: "a"; a: number} |
    {type: "b"; b: string};

function foo(x: T): string {
    if (x.type === "a") {
        return "" + x.a;
    } else {  // or else if (x.type === "b")
        return x.b;
    }
}

but it gives

test.js:9:21,23: property a
Property not found in
  test.js:5:5,26: object type

test.js:11:16,18: property b
Property not found in
  test.js:4:5,26: object type

(Let me know if I'm just misunderstanding how string types work.)

[avikchaudhuri]

This is an interesting use of string types. Will try supporting it. Basically it may boil down to us not being sensitive to === with string types, in which case the fix should be easy.

[sophiebits]

Curious: what's the intended use of string types?

[gabelevi]

Method overloading is the reason I most often hear. Like this example from the TypeScript Language Spec

interface Document {
  createElement(tagName: "div"): HTMLDivElement;
  createElement(tagName: "span"): HTMLSpanElement;
  createElement(tagName: "canvas"): HTMLCanvasElement;
  createElement(tagName: string): HTMLElement;
}

[RReverser]

+1 for this

[samwgoldman]

I've been thinking about this issue and I think I have an idea for how to implement this.

When x.type is refined, we install a refinement into the scope called $REFI x.type. We should be able to deconstruct that string to get the original identifier, x. Once we have that, we can look up the type of that var and if it is a UnionT, we can filter the list of types to be only those which are compatible with $REFI x.type and install another refinement on x itself using the filtered UnionT.

That doesn't help us if the type property is pulled off the x object then checked by itself, because we "forget" that the value of type is associated with the object x, I believe.

I know that implementation is pretty wild (string manipulation! yuck!) and its incompleteness is pretty lame too. Worth doing? Is there a better way?

[avikchaudhuri]

@spicyj Finally got around to fixing this, motivated by real-world use cases. We can now write ML in JS! ;)

[sophiebits]

Sweeet.

[samwgoldman]

Fixed in 0.13!

[RReverser]

@samwgoldman Thanks! Any plans for blog article with examples from the team?

[avikchaudhuri]

Blog post coming soon.

On Tuesday, June 30, 2015, Ingvar Stepanyan notifications@github.com
wrote:

@samwgoldman https://github.com/samwgoldman Thanks! Any plans for blog
article with examples from the team?

—
Reply to this email directly or view it on GitHub
#20 (comment).

[RReverser]

Thanks!