[cies]

When I see this it makes me want to run for ReasonML/ReScript/Elm/PureScript.

Sum types (without payloads on the instances they are effectively enums) should not require a evening filling ceremonial dance event to define.

https://reasonml.github.io/

https://rescript-lang.org/

https://elm-lang.org/

https://www.purescript.org/

(any I forgot?)

It's nice that TS is a strict super set of JS... But that's about the only reason TS is nice. Apart from that the "being a strict super set" hampers TS is a million and one ways.

To me JS is too broken to fix with a strict super set.

[int_19h]

TS does have sum types, so you can already do something like:

   type Color = "red" | "green";

What GP is doing is some scaffolding on top to make the values more discoverable and allow associating arbitrary Color-specific metadata with them.

[davorak]

I thought there were edge cases where sum types were not fully supported, nesting[1] is the example found first, but I thought there were others.

[1] https://github.com/microsoft/TypeScript/issues/18758

[int_19h]

Per the comments there, it still works if you use an explicit type guard function for checks, as opposed to checking the nested property directly, so I'd argue that the type itself is still supported in general, just not this particular way of testing for one of the options.

[davorak]

Maybe I am doing something wrong but when I fill in a concrete value for `aOrB` I still get a type error in that example code:

Playground Link: https://www.typescriptlang.org/play/?#code/C4TwDgpgBAglC8UDe...

I tried with 5.8.2 and nightly and the results were the same.

Interestingly, the playground reports aOrB(from github comment with concrete value) and aOrB2(modified) as the same type, `A | B`, but aOrB will give an error in the typeguarded if block but aOrB2 does not trigger an error. I do not know what is going on there either they do not really have the same type despite the playground reporting both as `A | B` or there is different bug going on.

So the solution presented in github does not look like a full solution as is.

[int_19h]

As far as I can tell, it's failing in the first conditional because it considers the type of `aOrB` to be `B` (rather than `A | B`) even before testing, based on it being initialized to B and then never assigned anything else. So when you apply the type guard, the resulting type of `aOrB` becomes, effectively, `A & B` (intersection), which of course doesn't have member `a`.

It would make more sense for TS to treat the body of the if-statement as unreachable and give a warning based on that, but I guess they figured that this kind of thing - doing a type guard on a value that is already known to be of a different type - is a very narrow corner case that isn't worth improving diagnostics for.

I'm more curious about why "smuggling" it through an array makes it work. In that case, the type of `aOrB2` remains `A | B` in the conditional, so everything is working as you expected, but I don't see the fundamental difference between this case and the previous one...

[davorak]

> As far as I can tell, it's failing in the first conditional because it considers the type of `aOrB` to be `B`...

The playground hover type annotation says aOrB is `A | B` at declaration and if you hover over aOrB in `if (hasTypeName(aOrB, "A"))` it produces `const aOrB: B`. Two types for 1 variable with no operations between. Not clear what operation is being performed on `aOrB`'s type that transforms it or if the playground type hover is just wrong.

> It would make more sense for TS to treat the body of the if-statement as unreachable and give a warning based on that, but I guess they figured that this kind of thing - doing a type guard on a value that is already known to be of a different type - is a very narrow corner case that isn't worth improving diagnostics for.

That does not seem to be the case, the type guard is not guarding what is in the if block, at least not consistently. It is not about the value being known at least, it is about the property being missing from what I can tell and the guards not being able to guard against it. If you have a top level `a` and `b` in both `A` and `B` there are no errors triggered:

    type A = {
        type: {
            name: "A"
        }
        a: number,
        b: undefined,
    }

    type B = {
        type: {
            name: "B"
        }
        b: number,
        a: undefined,
    }


    const aOrB: A | B = {
        type: {
            name: "A"
        },
        a: 1,
        b: undefined
    };

    // error as expect
    if (aOrB.type.name === "B") {
        console.log(aOrB.b) // Error
    }

    function hasTypeName<Name extends string>(a: { type: { name: string }}, name: Name): a is { type: { name: Name }} {
        return a.type.name === name
    }

    if (hasTypeName(aOrB, "B")) {
        console.log(aOrB.b) // no error
    }

    if (hasTypeName(aOrB, "A")) {
        console.log(aOrB.a) // no error here as well
    }

The guards not working or premature type narrowing(the inability to set a variable to a type and have typescript treat it as that type with the above type annotations).

[ninetyninenine]

TS sum types are actually more powerful thanks to 'as const'

These are dependent types which none of the languages above can enable. Meaning the type system can actually read values in your code and create types from the code. This is not inferring the type, this is very different.

For example:

   const PossibleStates = ["test", "me"] as const

   type SumTypeFromArray = (typeof PossibleStates)[number]

   let x: SumTypeFromArray = "this string triggers a type error as it is neither 'test' nor 'me'"

So in TS you can actually loop through possible states while in ML style languages you would have to pattern match them individually.

[pjmlp]

That single reason is all that matters, because it maps directly to what the platform actually understands, instead of adding another layer to debug.

[hombre_fatal]

On the other hand, pasting the `type ValueOf<T> = T[keyof T];` idiom into your TS code so you can use it for your enums is a hell of a lot less ceremony than ditching TS for any of the languages you listed. Especially when you can still just us TS enums if you wish.

And on top of that, each of them has a whole new collection of ceremonies you're going to have to learn.

All for what, to avoid `as const`?

[dkersten]

> (any I forgot?)

Gleam has real sum types and can compile to JS.

https://gleam.run/

[cies]

Indeed! I thought it was BEAM only...

[spankalee]

> It's nice that TS is a strict super set of JS... But that's about the only reason TS is nice.

I mean, yes, exactly?? That's TypeScript's entire reason for being, and it's no small thing.

I use TypeScript where I would have used plain JavaScript. If I have a reasonable choice of an entirely different language - ie, I'm not targeting browsers or Node - then I would definitely consider that.

I personally haven't seen that any compile-to-JS language is worth the interop tax with browsers or the JS ecosystem, and I've built very complex apps on GWT and used to be on the Dart team working on JS interop.

[Freedom2]

Civet (https://civet.dev) is probably my favorite one if I want something a bit fancier than Typescript, purely because it shares the same elements that you are as "opt-in" as much as you like, at least in my limited experience.