This is not a complete answer, but covers some languages. If you program too exclusively in dynamically-typed languages, you can be too used to not thinking about how physically large your types are, because you work in a world where everything is boxed, and allocations so plentiful you don't even hardly have a way of thinking about them because your language does them at the drop of a hat, and so on.

But there are many strongly-typed languages that look at types at compile time and decide how large they are, by which I mean, how many bytes of physical RAM they take. These languages have gotten better and better over time at the APIs they offer that give the benefits of this without incurring the programmer costs, but under the hood, no matter how slick they've gotten, there is still a mapping of type -> size & layout. In these languages, this sort of narrowing is a great deal more complicated, because it implies a new type, which will probably require more allocation. For instance, in the example given between a "string" and a "number", that definitely looks like two differently-sized types to me. This would become very complicated very quickly as you start having to allocate these things in ways that can't be transparent to the user, you have to pass these types around, etc. etc.

One would expect that the affordances of statically-typed languages would end up being very different. And in fact, they are. Many modern statically-typed languages can solve the same problems outlined in the post, they just solve it in a different way. In this case, an Either, or more generally, a sum type. Then "getViewsOf" returns a value of that sum type and you can switch on it based on the value. It isn't exactly the same, in fact I'm not sure there's one aspect of it that's the same let alone the whole, but it solves the same problems.

So my suggestion would be that there are in fact a lot of languages that essentially have the same feature. They just don't call it "flow typing" and it's not spelled the same way.

    interface A { type: 'a' }
    interface B { type: 'b' }
    type C = A | B;

    const c: C = ...;
    if (c.type === 'a') { /* c is of type A here */ }

The answer is simple: because other languages don't need it - they have different features to deal with it. The author even mentions it: pattern matching.

Just that he picks a language that doesn't support union-types. But that doesn't mean that flow typing would be necessary here - it means that the language(s) should support union-types and extend their pattern matching accordingly.

In fact, I would say that flow typing is almost like a workaround for missing pattern matching.

Nobody's mentioned dependent typing yet, but languages like Idris and Agda will "narrow types based on control flow" (in fact, since they're pure-functional, control-flow is the same as data-flow). For example, zipping two vectors of the same length:

    zip: Vec n t1 -> Vec n t2 -> Vec n (t1, t2)
    zip Nil Nil = Nil
    zip (Cons x xs) (Cons y ys) = Cons (x, y) (zip xs ys)

Here the 'Vec' type has two constructors, Nil and Cons. Since their types specify the same length, the type-checker knows we can ignore the 'zip Nil Cons' or 'zip Cons Nil' cases.

Contrary to what many comments here state, I don’t think this is only useful in a dynamic runtime kind-of environment. I often think I could use some form of this in Rust and/or Haskell. In a very specific way:

I often want a single constructor/branch of an enum (sum type) to a be a type as well, specifically a sub-type of the full enum. So once I learn about what branch a value is, I can treat it like that and even first class pass it around – without unpacking.

I think this should be implementable in Rust without any runtime overhead as pure syntactic sugar. You get the same effect by creating a new struct for every set of values per branch and using those wrappers instead.

    data Up
    data Down

    data Foo tag a where
        Up :: a -> Foo Up a
        Down :: String -> Int -> Foo Down a

It's not really called out as such, but the C# 8 feature Nullable Reference Types is an example of deeply embedding flow typing into a language. The nullability state of a reference type can change based on many things you can do in code. It's really neat and extremely intricate.

This is called Type Narrowing by the way. Control flow analysis is only one way this works in TypeScript.

Most languages don’t have the type system necessary to make this work in a sensible way.

See also “Occurrence Typing” in Typed Racket. [^1]

> One of Typed Racket’s distinguishing type system features is occurrence typing, which allows the type system to ascribe more precise types based on whether a predicate check succeeds or fails.

One of the big advantages is that it lets a text editor use the added information to supply better auto-complete suggestions. It also makes it possible to eliminate some safety checks at runtime because the type checker has ensured that certain calls will be safe based on prior conditional checks.

[^1]: https://docs.racket-lang.org/ts-guide/occurrence-typing.html

Dart does this, or at least something very similar, and it is really nice. It's most useful for narrowing nullable types to their non-nullable counterparts after a null-check, but the subclass case works too.

Doesn't "flow typing" seem more like a bandage for the if-statement in languages that have nothing better.

There is a language construct which is purpose built for unpacking sum types: The case expression (sometimes called match expression)

  case resp of
    Views n -> ...
    Error e -> ...

Inside each branch, we have access to a value of the more specific type.

  let idx = randomInt();
  if (0 <= idx && idx < arr.length) { // proposition introduced
    // idx now has type: int where 0 <= idx && idx < arr.length
    // irrefutable proof of safe indexing by type propositions
    let value = arr[idx];
  }

> Even in the presence of such tests, Java demands that the author cast their objects appropriately.

This is one of the many reasons why I've found Kotlin so refreshing after five years of writing enterprise Java

https://kotlinlang.org/docs/typecasts.html#smart-casts

I looove flow typing / type narrowing. HTDP taught how to think through it (data type narrowing / checking for and handling different types) while building functions. TypeScript let's me enforce the same process with intellisense warning me whenever I get off track. It's been a joy to see how quickly and solidly the code stacks up.

I'm trying to design a programming language that can be compiled into C99 and it's not at all clear to me how you represent these things statically.

The idea from a programming point of view is really nice and in a dynamic programming language environment everything is an object and you can pass whatever through any function. This doesn't work all that well if you want to translate your program into a statically typed environment, in a cost effective way.

You need some way to reason about the type information that hopefully doesn't create memory allocations all over the place.

This can be done by introducing tagged data types but it can also lead to a combinatorial nightmare where you need to generate a lot of extra code.

In general, I don't think all this complexity is warranted in a statically typed environment and depending what you are doing this doesn't end up being that important. Even if, it's a nice to have, it's mostly that, a nice to have.

So I've been working on a personal project which is in a mix of C++ and TypeScript -- partially because of practicality and partially to learn TypeScript, and I'm really liking the language.

One question I have is whether there's any possibility that TypeScript could, in the long run, gain performance advantages over pure JS? That the compiler could leave behind some type information artifacts so that V8 (or similar) could use that information at runtime to optimize method dispatch and other operations?

Likewise with the flow pieces mentioned here, I gotta think that the VM could optimize out certain runtime checks on dispatch or conditional branching if it knows that the compiler has already checked for these?

fyi Java 16 did add pattern matching for instance of so you can avoid the cast.

  if (o instanceof String s) {
    var foo = s.indexOf("bar");
  }

  return switch (o) {
     case Integer i -> String.format("int %d", i);
     case Long l    -> String.format("long %d", l);
     case Double d  -> String.format("double %f", d);
     case String s  -> String.format("String %s", s);
     default        -> o.toString();
  };

Kotlin does this, it's great.

This question actually has a simple answer:

Most languages have embraced statements over expressions for a lot of language constructs.

This causes a lot of issues:

An if-statement is in essence a function from boolean to unit/() (i.e. from a barely useful type to a type with no useful information), while an if-expressions will contain enough type information to at least provide this kind of “flow typing”, (even if it induces an amount of boolean blindness.)

It’s even worse when you get to loop-statements, which often is a function from unit/() to (unit/() | bottom/⊥), compared to a map or a reduce or fold, which again provide enough type information to provide this kind of “flow typing”.

Sometimes you will of course need to provide impure conditionals or loops, but that can be made explicit in the type system.

IMHO statements in programming languages are an anti-pattern.

    if (foo is! Bar) return "not a Bar";
    foo.someBarMethod();

What’s the difference with type inference? Is it that flow typing can happen at runtime for just in time /noncompiled languages?

Unless you build a compiler around it it's probably quite hard to implement

... isn't this just OOP inheritance/subtyping/interface implementation with if/then checks for the more specific types?

I work on a language, Dart, which also relies heavily on flow typing (which it calls "type promotion" because apparently every language needs their own name for it). We use it both for subtype tests and null checks. It's really nice and a large net win for Dart especially given its history.

However, if I had a time machine and could redesign Dart from scratch, I would be tempted avoid flow typing and instead do something more like Rust and Swift do: Variables keep their static type but have pattern maching and nice syntactic sugar for simple use cases of it to make it easier to bind new variables with the narrowed type.

The main problem is that flow typing is very complex, subtle, and can fail in ways that users find surprising. For example:

    foo(Object obj) {
      closure() {
        obj = "not int any more.";
      }

      if (obj is int) {
        print(obj.abs());
      }

      closure();
    }

This function is technically safe, but it's very hard for static analysis to reliably prove what kinds of flow analysis are valid when closures come into play. If that closure can escape, it can be impossible to prove that it won't be called before the variable is used.

A simpler, more annoying example is:

    class C {
      Object obj;

      foo() {
        if (obj is int) {
          bar();
          print(obj.abs());
        }
      }

      bar() {}
    }

This code looks like it should be fine. But if C is an unsealed class and some subclass overrides `bar()` to assign to `obj`, then the promotion could fail. Because of this, Dart can't promote fields and it causes no end of user annoyance. Top-level variables and static fields have similar limitations.

Even when it works, it can be surprising:

    foo(Object obj) {
      if (obj is int) {
        var elements = [obj];
      }
    }

Should `elements` be inferred as a `List<Object>` or `List<int>`? What about here:

    foo(Object obj) {
      if (obj is int) {
        var elements = [obj];
        elements.add("not int");
      }
    }

Should that `add()` call be OK or an error?

Flow analysis is cool and feels like magic. It does the right thing 90+% of the time, but there's a lot going on under the hood that pops up in weird surprising ways sometimes.

It's probably the right thing to do if your language has already invested in an imperative style. But if you have the luxury of defining a language from scratch, I think you can get something simpler and more predictable if you make it easier to define new variables of the refined type instead of mutating the type of an existing variable.

Dart is heavily imperative, so I think flow analysis makes sense for it. Accommodating an imperative style is one of the main things that makes Dart so easy for new users to pick up, and that's an invaluable property. But I admit I envy Swift and Rust at times.

We don't hold language authors accountable, and accept mediocrity.

Is this something like GADT's?

Hafiz writes:

> almost every enterprise Java codebase I've had to work with has observed this pattern of testing whether an object is an instance of particular subclass, and using that to drive further computation. Even in the presence of such tests, Java demands that the author cast their objects appropriately. Of course you can always introduce an intermediate variable after the test, but I argue that this is still too much—upon verifying the instance of an object, the type system should be smart enough to update the object's type appropriately!

Because Java considers null to inhabit every type, in a Java project a few years ago, I handled this in a dynamic_cast-like way, as follows (abbreviated):

    public abstract class Security {     // ...
        public Stock asStock()   { return null; }
        public Future asFuture() { return null; }
    }

    public class Stock extends Security { // ...
        public Stock asStock() { return this; }
    }

    public class Future extends Security {
        public final SecurityTable factory;
        public final String exchange, symbol; // ...
        public Future asFuture() { return this; }
    }

This allows you to write relatively uncluttered type-dispatching downcasting code like this:

            public boolean contains(Security sec) {
                Future f = sec.asFuture();

                return f != null
                       && SecurityTable.this == f.factory
                       && f.symbol.equals(symbol);
            }

Of course this violates the open-closed principle (the abstract base class should be closed for modification) and official OO doctrine is that if you want different behavior for different subclasses you should put that behavior into a method that gets overridden by the subclasses, not in a conditional that attempts a downcast, so we did that a lot more often. But I found it a pleasant solution to the problem in the context of this Java project.

Of course it doesn't help in languages without implicit nullability, like TypeScript, which would ideally be all statically-typed languages.

— ⁂ —

The big difficulty with flow typing is, as I see it, not that it clashes with nominal typing; it's that it incorporates your compiler's static control flow analysis capabilities into your language's type system. Consider Hafiz's Java example:

        if (node instanceof DomNode.Element) {
            Layout layout = ((DomNode.Element) node).layout;
            return new RenderNode.Styled(layout, /* ... */);
        }
        return new RenderNode.Noop(/* ... */);

It is entirely reasonable to request that the type system handle this and allow you to write:

        if (node instanceof DomNode.Element) {
            Layout layout = node.layout;
            return new RenderNode.Styled(layout, /* ... */);
        }
        return new RenderNode.Noop(/* ... */);

But how about this? Now we're no longer inside the static extent of the `if`, and we're depending on the compiler to recognize the unconditional early return:

        if (!(node instanceof DomNode.Element)) {
            return new RenderNode.Noop(/* ... */);
        }
        Layout layout = node.layout;
        return new RenderNode.Styled(layout, /* ... */);

How about constant folding and partial evaluation?

        if (1 == 0 || node instanceof DomNode.Element) {
            Layout layout = node.layout;
            return new RenderNode.Styled(layout, /* ... */);
        }
        return new RenderNode.Noop(/* ... */);

Do we want to skip type checking entirely for dead code? Straightforwardly flow typing gives us that the type of every variable inside unreachable code is void, the uninhabited type, so any operation whatsoever on it is type-valid. Do we want the compiler to accept code like this?

        if (1 == 0) {
            Layout layout = node.layout + node / node;
            return new RenderNode.Styled(layout, /* ... */);
        }
        return new RenderNode.Noop(/* ... */);

And of course doing control-flow analysis precisely isn't feasible due to the halting problem; you need to do some conservative approximation.

So, if you want your programs to be portable from one version of the compiler to the next, somewhere you need to write down precisely what conservative approximation you're using for control-flow analysis, and in particular what you're not.

I forgot about flow typing. Is that still an option on iOS?

> In fact, I would say that flow typing is almost like a workaround for missing pattern matching.

If flow typing is 'type narrowing' (the article kinda dragged on pulling in unrelated concepts so it lost me), then if anything, it is at least as good as pattern-matching/switch-blocks. At least in Typescript. That is because it works in switch statements and non-switch statements and provides the same guarantees. I don't get this argument.

Consider something like:

    data: {pages: number} | null = f()
    if (!data){
       return 0
    }
    return data.pages + 5

Sure you can switch on the 'data' as well (exhaustive type-switches are a thing in Typescript too), but thats a syntactic preference. It surely is nice to get the same guarantees without _needing_ a switch statement.

    let data: Some(usize) = f();
    match data {
        Some(pages) => pages + 5,
        None => 0
    }

    let Some(pages) = f() else {
        return 0
    };
    pages + 5

I don't think pattern matching and union-types makes narrow typing useless. Rust has both pattern matching and union types but still implements some specific forms of control-flow based typing.

For example, consider this Rust snippet :

    pub fn positive1(x: isize) -> Option<usize> {
        if x > 0 { Some(x as usize) } else { None }
    }

Unless I'm mistaken, without narrow typing, this cast would be impossible, and there would be no way to avoid the redundant runtime check caused by try_into().unwrap(), that is not even optimized unless you trick the compiler.

You need flow typing when you do pattern matching on generalized abstract data type (GADT). Here is an example in Java

    sealed interface Foo<T> permits Impl {}  // union type
    record Impl() implements Foo<String> {}  // product type

    <T> T m(Foo<T> foo) {
      return switch(foo) {
        case Impl impl -> "hello";  // flow typing T=String 
      };
    }

Yeah, the same code would look much clearer in a language with union types. Heck even Swift cribbed them.

switch resp {

  case Result(val, meta):

    doStuff(val)

  case Error(msg, code):

    logger.main.debug(msg)

}

In Kotlin this is called smart casts. It works great.

Doing a null check means that after that you can treat the variable as non nullable. Doing a type check, narrows down the type to what you just checked. Or going down a switch statement branch on the type actually implicitly does the cast as well.

It's both strongly typed and convenient.

Kotlkin even goes a step further and introduced contracts few versions ago that you can bind to functions. For example calling isNullOrBlank() on a nullable string changes to the type to nullable if the answer is false. You can write your own contracts for your own functions even. This is what the source code for this function looks like:

  @kotlin.internal.InlineOnly
  public inline fun CharSequence?.isNullOrEmpty(): Boolean {
    contract {
        returns(false) implies (this@isNullOrEmpty != null)
    }

    return this == null || this.length == 0
  }

I guess typescript does something similarish.

    function isFish(pet: Fish | Bird): pet is Fish {
      return (pet as Fish).swim !== undefined;
    }

    // Both calls to 'swim' and 'fly' are now okay.
    let pet = getSmallPet();
 
    if (isFish(pet)) {
      pet.swim(); 
    } else {
      pet.fly();
    }

    function assertIsDefined<T>(val: T): asserts val is NonNullable<T> {
      if (val === undefined || val === null) {
        throw new AssertionError(`Expected 'val' to be defined, but received ${val}`);
      }
    }

    function doSomething(pet: Fish | undefined) {
      assertIsDefined(pet);

      // safe to use without checking for null/undefined,
      // because our assertion function narrowed the type for 
      // usage later in the function 
      pet.swim();
    }

I really enjoy Typescript, but every time I use it I think to myself, this would be so much better if were built on top of something other than JavaScript. Maybe AssemblyScript or some other TS to WASM target will come along with a better underlying type system and a good standard library. Dare to dream.

V8 already does this.

When you write your code in a way that is akin to what you would do in a static environment, V8 emits additional type checks, if these pass, then it will run your code through a optimized version of the code that makes certain assumptions about the data types in use. If these type checks fail, then V8 will deoptimize the function/code.

Deoptimization needs to happen because the assumptions made about the execution of the code was wrong and the optimized code cannot handle this special edge case. V8 will then revert to less optimal code for the specific case but this code is more general and can handle the special case that occurred.

V8 can and will toggle between optimized and unoptimized versions of your code now and then but it has limits. If it cannot settle on a version of your function that is optimized it will stop trying to optimize the code because the cost of doing so is significant.

When you write your JavaScript as if it was more statically typed than it actually is, you do enjoy optimization benefits from V8.

Unfortunately a big issue in TypeScript is that objects can and surprisingly often do have the completely wrong type. Some libraries even blatantly violate their TypeScript types. So any optimizations which take advantage of TypeScript types are likely to lead to very hard to debug behavior.

A better option is to make/use a language which interfaces well with JavaScript but is not JavaScript and actually checks it’s types. If the type system is actually be sound, and any code going in from JavaScript is type-checked at runtime, then compiler optimizations are reasonable.

As for your last point, I know that JIT-compilers like V8 can and do infer types at runtime (e.g. by noticing if a particular variable or function arg is always set to the same type) and will compile specialized function overloads which take advantage of the inferred type for optimizations (e.g. using fixed-width integers even though all JavaScript numbers are doubles).

In this example, it's why Java added sealed interfaces, otherwise left with ∞ - 1 possibilities.

  if (!(node instanceof DomNode.Element)) {
    return new RenderNode.Noop(/* ... */);
  }
  Layout layout = node.layout;
  return new RenderNode.Styled(layout, /* ... */);