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.
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). /be ----- Original Message ----- From: "Axel Rauschmayer" <[email protected]> To: "es-discuss" <[email protected]> Sent: Thursday, December 29, 2011 5:38:54 AM Subject: Preparing for type guards Once we have type guards, I would expect the JavaScript programming style to slightly change. Currently, number-valued arguments are implemented like this: function foo(x) { x = Number(x); } With guards, you would use: function foo(x :: Number) { } It might make sense to standardize simple guard methods now, for example: function foo(x) { Object.guard(x, Number); } Advantages: Helps tools (to infer types, to generate documentation), can later be refactored to real guards. -- 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
