TypeScript: Control flow analysis for destructured discriminated unions

If some of the noise were eventually removed and tagged unions became true first class citizens in TS' syntax, I think some of these colleagues without as much typing experience might be more open to the idea—or at the very least understand it in the first place.

I'm trying to think of a reason why the compiler couldn't allow that destructuring, implicitly type the values missing in some components of the union as 'T | ... | never', then lean on the control flow analysis it looks like we're getting in 4.6 to specify the type as the discriminated union is de-discriminated (lol). JS itself does allow the destructuring of elements missing from an object, they come out as undefined, so I don't believe there'd be any underlying issues.

Hopefully we see it in 4.7!

A better example: think of Kubernetes API objects. In short, expressed as typescript interfaces:

    type KubeObject = Pod | Service;
    interface Pod { kind: "Pod", metadata: Metadata, spec: { containers: Container[] } };
    interface Service { kind: "Service", metadata: Metadata, spec: { selector: ServiceSelector } };

    const f = ({ kind, spec: { containers, selector } }: KubeObject) => {}

That's very interesting. Could you please provide an example that showcases that inconsistency?

>"While I have a lot of respect for the creators of TS,"

Creators of TypeScript are Microsoft.

To any readers unfamiliar with TypeScript and Microsoft's ethics,

be sure to research their past corporate ethics to understand whether or not they are trustworthy as a company (or at least those who lead their overarching market strategies.

Here is one example, and to me, it describes where TypeScript is going (imho):

"The strategy's three phases are:

---> Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.

---> Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard.

---> Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions."

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

For this reason, out of sheer convictions in anti-unethical corporate behavior, I steer clear of TypeScript, and I encourage others to do so as well-- especially those who care about corporate ethics.

It seems matsemann fundamentally missed the idea of TypeScript, as it's very clear it only offers compile-time checks and nothing for the runtime.

https://redux.js.org/tutorials/typescript-quick-start

A bit hard to provide an mvc of the issue I'm thinking of. But I often see it happen with HOC kinda stuff. Like I might have a loader component, that I pass three things to: the query to run, a component to render, and some additional props to the component to render. The render component will get the props, plus the result of the query as well.

When adding typing to this, ts will naturally complain. So fix that by adding generics etc. And then everything looks fine according to the ts compiler, so you're happy.

But if you try to change the typing of the inner component, or some type of the props being sent to the outer component, you might find that ts is still happy. Somewhere along the line, it decided to throw its hands up and allow everything. So the typing is just complex noise, not catching subtle bugs.

Of course, people could easily write a correct example handling this. But the problem is that there are so many complex ways to solve stuff in ts, and some of them are wrong even though they look correct.

Some of it might be fixed using a stricter setup as you mention.

    function x(y: {
      foo: number,
      bar?: number
    }) {}

    const y = {
      foo: 1,
      baar: 2, // typo
    }
    x(y)

TS issue https://github.com/microsoft/TypeScript/issues/12936

TS has a concept of "freshness" which catches some of these mistakes when you construct y right in the arguments of x, but it gets easily broken by accident and without a warning.

2. Nominal types, so you can have for example "Id" type that is a number but not to be mixed with other numbers, you can't just call a function that expects an Id with literal 42. Classes are nominal too, which I think is a solid choise.

3. Type variance & related safeguards

    function x(y: {
      foo: string | number
    }) {
      y.foo = 1
    } 
    const y: {
      foo: string
    } = {foo: 'a'} 
    x(y) 
    y.foo.toUpperCase()

4. Local call site type inference of function argument types, so you can have some helper functions within a file that you don't need to explicitly annotate, and Flow will happily infer types based on how you call it.

5. Performance has gotten prerty good with recent versions, to the point where I suspect it's faster than TS. I don't have any hard data on this though.

Even though in many many ways Flow is worse than TS, we have still stuck with it, and that's only like 80% because it'd be s huge undertaking to make the switch. 20% is because some of these features are actually nice :)

I think that's it these days. Flow used to have (slightly) more features but now TS has way more already and even more to come. The Flow people moved on to Recript, or whatever name they call it these days.

“What’s a union?”

“Okay… then what’s a discriminated union?”

“Okay… let’s apply destructuring to one…”

“Okay… now what would analysis look like there given what I know?”

“Okay… how do we have the computer know what I know intuitively as a human given this context?”

“Okay! I think I got it!”

:-). If you’ve gotten this far with programming to understand the examples above, my guess is if you just take the time you can do it without the examples if you take it in small enough chunks :-).

Life’s all about what you apply your energy too

(And also, wonderful example :-) )

    type HttpVerb = "GET" | "POST" | "PUT" | "DELETE";

    type User = {name: string; password: strings} | OAuthID;

As an aside, compared to sum types, you don't have to define them before using them: a function can return number | null while in language with sum types you usually define option first and then return option<number>.

In a language like TypeScript, they can be used for function overloading since there is no runtime dispatch based on argument type. But usually they're used as sum types in the same way as e.g. Rust enums.

Typescript supports so-called "singleton types", in which a given type is inhabited by exactly one value. This lets you do things like specify not just `string` but specific values like `"foo" | "bar"` as a type. In these cases, I often use them in combination with Typescript's "mapped types", which let you index into a map with a certain type and get another type out. This can be useful for things like RPC calls, where the type of the output depends on the type of the input.

To illustrate how TS discriminated unions are functionally equivalent, check out this playground link showing how ReScript (an alternate syntax of OCaml which can compile to JavaScript) compiles an OCaml variant to a JavaScript object with a "TAG" key that could easily be typed as a discriminated union in TypeScript:

https://rescript-lang.org/try?code=C4TwDgpgBAThCOBXCBnYBlYBD...

On the other hand, Rust's enum have to be defined before use: I can't suddently decide to have a function that returns "Toto" | "Tata" without creating a type or returning string.

OCaml has something called "polymorphic variants" that seem to be a middle-ground between the two: https://ocaml.org/manual/polyvariant.html.

But as always, context is king and no solution fits everything. But hype makes it seem like a tool fits everything, to the detriment of everyone else.