This is very high praise for something that only provides safety at compile time and not runtime.
This is very high praise for something that only provides safety at compile time and not runtime.
TS might not be the most robust type system in the world with no qualifiers. And it might not even try to be sound. And it might disappear at compile time. But none of that changes the fact that it took a bunch of concepts that only programming language dorks knew or cared about and turned them into every day utilities that the junior most developers use. And it doesn't change the fact that it is the only mainstream programming language with a fully Turing complete type system.
Give credit where it's due. I say all of this as one of the aforementioned programming language dorks who took a really long time to get on board with TS, as I thought Flow's focus on purity made it a better choice.
If you told me that was the case today with web developers generally, I’d laugh at you even harder than I would have if you made that prediction ten years ago.
Similarly, a function that accepts (explicitly) `A | B | (C & D)` and then dispatches to functions that accept `A | (C&D)` vs `B` is, you guessed it, type algebra and is a common pattern in hot paths through every TS codebase.
Just because the formal nomenclature is unknown does not mean the concepts are unfamiliar.
It's the opposite in my experience. Most web developers I work with (a lot because of consulting), specially the average "React sprint runner" doesn't have a clue about anything slightly above basic types and just google/chatgpt whenever things break so they can move on to the next task in the sprint.
cryptic typescript errors don't help here either.
type Thing = string | boolean;
const arr: string[] = [];
function add(item: Thing, dst: Thing[]): void {
dst.push(item);
}
add(false, arr);
Is valid typescript.However, regularly it's not the case -- especially with people moving from nominal systems.
TS can't really be practically nominal when it has to be constrained by its compile target. So I guess it ultimately boils down to an anomaly/criticism born from the legacy of how web standards came about.
But yeah unfortunately not sure if JS is an appropriate target for these type systems. Nim does it, but I'm not sure how safe it is.
type thing =
| String(string)
| Bool(bool);
let arr: list(thing) = [];
let add = (item: thing, dst: list(thing)): list(thing) => {
switch (item) {
| String(s) => dst @ [String(s)]
| Bool(b) => dst @ [Bool(b)]
};
};
let newList = add(String("asd"), arr);
This doesn't work, since the dst array has to be one that can contain both string and bool in the first place.I understand it may be unwanted at first glance, but this is a contrived example for demo purposes. You wouldn't really make an "add to array" function like this so specifically. You would use generics, which would solve the exact issue that is posed.
function add<T>(item: T, dst: T[]): void {
dst.push(item);
}
Now you can work with any array, and it will only add items with the right type.If you really need it to be just <Thing>, you can do this
function add<T extends Thing>(item: T, dst: T[]): void {
dst.push(item);
}
Now it knows that Item and DST are related but need to be Thing.There's not a lot of languages with unions that handle this differently. F# discriminated unions make you specify which type you're using every time. For example, this doesn't even compile.
type Thing =
| A of int
| B of bool
let arr: Thing list = [1] // Not an A or B type!Because some checks are expected to be runtime only, it lets you specify types like "Odd integers" by writing a `where` clause.
``` subset OddInteger of Int where !(* %% 2) ```
You can use multiple dispatch to separate dispatch from processing: ``` subset Fizz where * %% 3 subset Buzz where * %% 5 subset FizzBuzz where * %% 15
multi sub fizzbuzz(FizzBuzz $) { 'FizzBuzz' }
multi sub fizzbuzz(Buzz $) { 'Buzz' }
multi sub fizzbuzz(Fizz $) { 'Fizz' }
multi sub fizzbuzz(Int $number) { $number }
(1 .. 100)».&fizzbuzz.say;
```Or even use inline anonymous subsets when you declare your functions: ``` multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' } multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' } multi sub fizzbuzz(Int $ where * %% 3) { 'Fizz' } multi sub fizzbuzz(Int $number ) { $number } (1 .. 100)».&fizzbuzz.say; ```
Raku's type system is one of its features that will show you new ways of thinking about code. I advocate playing with Raku specifically for mind expansion because it has so many interesting ideas built in.
For runtime safety, there are lots of frameworks that follow TS's standard, one of the best is called "zod" which allows runtime safety and complex types are inferred.
Anyway, you can get this with Zod https://zod.dev/