3 ms·
If you are used to structural typed systems though this actually "feels" expected. Don't get me wrong, I know where you are coming from. But the realisation com
by adamscybot 2y ago
If you are used to structural typed systems though this actually "feels" expected. Don't get me wrong, I know where you are coming from. But the realisation comes from nominal systems, which are different beasts. As long as it actually evaluates to the expectations in the head of the developers using it, then that's okay.
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.
- consteval 2y agoNominal type systems are pretty much better across the board IMO. Much safer and much less to keep in your head. Modern langs like Rust or F# have very complete and nice to use type systems. 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.
- adamscybot 2y agoOne language that comes to mind is ReasonML. It doesn't have runtime checking. It's structural and compile time, but the guarantees are supposedly cast iron. https://reasonml-old.github.io/guide/language/type#design-decisions https://reasonml-old.github.io/guide/language/type#design-de... 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.