Actually, it's even simpler: you should just be able to use signature overloading:

  myFunc(x: true): number
  myFunc(x: false): string

The article's assertion that TypeScript can't represent this is quite false.

Alas, no:

    foo.ts:1:10 - error TS2393: Duplicate function implementation.

Like this:

https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABA...

It's a bit of a hack, though - if you incorrectly implement myFunc so that, say, it returns a string even when x is true, it can violate the overloading assertions without any error or warning.

Thanks! If anyone else is playing along, to get this to work with tsc I needed to use "--strict".

Being able to use a function along those lines in a type safe manner is still pretty nifty, even if you can't write it with type safety.

No, because 1) you can't do (full) dependent types in TypeScript, 2) it's not clear what "dependent types" would even mean without type checking, and 3) using the union type you aren't giving up type checking at all.

The limitation is what comes later in the article - the dependent type can express the relationship between the argument and the returned type. But that's "out of scope" of the question of "typing a function that can return either a number or a string depending on the boolean argument". It only becomes a problem later on because to use the result you need to test the type (using `typeof`) even if you know you which boolean you passed in; that information doesn't end up tracked by the type system - although there actually are a couple of different ways to do this that satisfy this example in TypeScript, as suggested by some other comments.

Just using a union type in TypeScript isn't dissimilar to my suggestion of wrapping the result in an ADT; it's just that TypeScript makes this lightweight.

The dependent type question is, I think, subtly different: "a function whose return type is either a number or a string depending on the boolean argument."

The union type (or the more or less equivalent Either ADT) don't give you type checking because you can take either (sic) branch no matter what your boolean value was. You're free to write a function that takes false and returns an int, and the type checker will accept that function as correct.

No matter how you twist and turn in GHC Haskell or TypeScript, you can't prevent that just by the type signature alone, so you have to "trust me bro" that the code does what the comment says.

For this example that's trivial and laughable, but being able to trust that code does what the compiler-enforced types say and nothing more is perhaps a step towards addressing supply chain attacks.