3 ms·
You skipped over the first part "Has no pitfalls, aka the type system is "sound" (the types will always be correct). E.g. If a type isn't marked as nullable, it
by foota 4y ago
You skipped over the first part "Has no pitfalls, aka the type system is "sound" (the types will always be correct). E.g. If a type isn't marked as nullable, its value will never lie and let through some undefined value silently. ReScript code has no null/undefined errors."
E.g., if a type returned from a function is nullable then you will be forced to handle that explicitly via pattern matching I imagine, rather than being able to dereference it without checking.
- wruza 4y agoMy question is how this sound is made, omitted it for citation reasons. Does this mean that a developer has to create sound wrappers for all external interfaces, which aren’t aware of rescript? It may be viewed as a burdensome perspective. Language bridges usually try to auto-wrap this and throw when something doesn’t match expectations, but it comes at a runtime cost.
- marcus_cemes 4y agoThe type inferrence only applies to ReScript code, it's not a magic compiler that can statically analyse JS code and generate interfaces for any arbitrary npm package. For Typescript interop, it can "trust" the TS declaration files, but there is no real guarantee when you're crossing language boundaries. ReScript is it's own language, with it's own type system that compiles down to JS. I don't think there's a reasonable alternative to this. Take Rust, calls to C code are inherently unsafe, and must be marked as so. You're leaving Rust's source code and type system and calling into external functions that you may not even have access to source code for and that the compiler just can't feasibly vouch for.