I went looking for where on their website they claim to be sound. There's definitely some misleading wording here: https://flow.org/en/docs/lang/types-and-expressions/#toc-sou... but if you read the whole section, it ends up also acknowledging that it's not entirely sound.

https://flow.org/try/

Compare these two programs.

    const arr = ["abcd"];
    const str = arr[1];
    const num = str.length; // this throws at runtime

    const arr = [new Date];
    const dt = arr[1];
    const num = dt.length; // fails to type check

    main = putStrLn (["a", "b", "c"]!!4)

The result of the an OOB access of an array is specified to be `undefined`. The throw only happens later when the value is treated as the wrong type.

I don't consider a runtime error to be a failure of the type system for OOB array access. But in javascript, it's explicitly allowed by specification. It's a failure of any type system that fails to account for this specified behavior in the language.

This is like arguing that a null exception is fine because it's allowed by the language. If you get `undefined` when you expect another type, most future interaction are guaranteed to have JS throw because of the JS equivalent of a null pointer exception. They are technically different because a dynamic language runtime can prevent a total crash, but the effect on your web app is going to be essentially the same.

    [1,2,3][4].toFixed(2)

Haskell has the ability to handle the error.

How do you recommend a compiler to detect out-of-bounds at compile time? It can certainly do this for our trivial example, but that example will also be immediately evident the first time you run the code too, so it's probably not worth the effort. What about the infinite number of more subtle variants?

I wouldn't make the recommendation that they do at all. Full soundness is not my thing. But... if Flow wanted to do it, it would have to change the type of indexing into `(Element[])[number]` with a read from `Element` to `Element | undefined`.