> Aren't you assuming a certain kind of guards, namely converting rather than
> throwing? There's no way to future-proof without more agreement on what the
> default meaning of x :: Number would be, and (AFAIK) we don't have consensus
> yet.
Yes, in the future of JavaScript, I’d expect more throwing and less converting.
> Anyway, no one is going to start writing imperative mouthfuls such as
> Object.guard(x, G) all over. That's not wanted. If guards arrive with
> compatible semantics, then people would have to plow through their code
> removing all such boilerplate in favor of guard syntax. But that's a
> best-case scenario.
>
> Also, just on the number point: people don't all write x = Number(x). You'll
> see x = +x, or an application-specific conversion -- or no conversion at all
> (which could be a bug, but might not be due to constraints enforced
> elsewhere).
My main points are: I think the JS programming style is going to change from
converting to throwing. IMHO, that would be positive, it would reveal errors
more quickly. If that is true then can/should we prepare for this and how?
I’d still favor the simplest possible type guards for ES.next, with the option
of more features in the future.
Apart from something imperative, I can also imagine tools turning JSDoc-style
type comments into runtime checks:
function add(/*number*/ x, /*number*/ y) { ... }
Most of Dart’s type system is much closer to JavaScript + minimal type guards
than I initially thought. That’s a part of it I really like.
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
