Claus Reinke wrote:
Ultimately, I'd like to have both:- irrefutable matching: here, the two phrases above are equivalent, as in the destructuring proposal - refutable matching: here, the latter phrase would fail, ideally in a way that can be recovered from efficiently, to guard against interfacemismatches and to implement pattern matching with fall through, as in the pattern_matching strawman "switch/match"One is a syntactic convenience for selection only, the other for selection plus structural tests (actually: behavioral interface tests, see below). Both have their uses.
Agreed.Also don't get your hopes up for structural as in record types. We can't future-proof against all futures, but we have a dual form to object and array literals in ES6: destructuring. This means making some choices, now, even if in the future we *add* new forms that make other choices.
This suggests having pattern syntax modifiers for indicating refutable or irrefutable matching, and deciding which of the two is likely to be more common (and thus to be the default for patterns without modifiers).
If there's a modifier-free default, then there's not much case for an explicit modifier. The only future-proofing is to allow a new syntactic form to use a destructuring pattern to do a refutable match. That's what Dave's proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matchingwas about, but it didn't make ES6 for want of time to fully bake. Still, apart from the catch clause issue, it uses new syntax to imply "refutable, not the default".
So I don't think we need two modifiers, and from the duality of object/array literals and destructuring, it seems to me that destructuring must be irrefutable in the sense you give: the equivalence between
let myFoo = {a:0,b:1}.foo;
and
let {foo: myFoo} = {a:0,b:1};
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
