On 5 July 2012 20:14, Brendan Eich <[email protected]> wrote: > Then the question is: should we value the current equivalence more and > make the pattern-matching equivalence use-case pay the prefix-! syntax. > IOW, keep > > A: > > let {foo} = bar(); > =~ > let foo = bar().foo; > > and impute undefined if foo is missing in the object returned by bar(), > and require > > { let {!foo} = exp; console.log(foo) } > =~ > match (exp) { case !foo; console.log(foo); } > > Without the !, the match would bind undefined to the case foo local. > > Or should we do as you propose, and require prefix-? to get the > impute-undefined-on-missing-**property behavior needed for the first > equivalence, call it > > B: > > let {?foo} = bar(); > =~ > let foo = bar().foo; > > At least this way, match does not need ! to work as pattern-matching users > expect: > > { let {foo} = exp; console.log(foo) } > =~ > match (exp) { case foo; console.log(foo); } > > Allen rallied me to the prefix-! route by objecting that prefix-? would > not be available outside of patterns, which simply highlights how JS > already imputes undefined for missing property. > > I feel the burden of the first equivalence acutely, since I implemented > destructuring per the ES4-era proposal to look like (A) above, based on > Opera's engine of the time, and Rhino and probably other engines followed > suit. This experience means compatibility breaking pain, and what's more: > user-testing something new, unscientifically as ever but in much less time > than we've had to hear about bugs due to (A). > > However, I agree that requiring prefix-! in > > match (exp) { case !foo: ... } > > is onerous if we choose the impute-undefined path, and worse: that a > missing prefix-! is both likely to happen (a footgun), and nonsensical for > pattern matching. > > So (B) wins if we want pattern-matching. > > We should talk more at this month's TC39 meeting, but I see a sharp divide > ahead: > > 1. Choose (A), possibly with modification, either rejecting useful pattern > matching decisively, or else making its pattern language differ by making > prefix-! implicit. But you rejected splitting pattern meaning across > destructuring and future pattern-matching, in the last sentence cited above. > > XOR > > 2. Choose (B) because future-proofing for pattern matching wants prefix-?, > and impose a compatibility break from what we and others implemented, and > what most JS users might expect based on JS's carefree imputing of > undefined. >
Agreed. Comments from es-discuss peanut gallery welcome. > I could go for 1/A, except for two facts. First, I believe there is a > non-trivial body of Firefox JS that depends on imputing undefined. Second, > and what is more important: we haven't usability-tested 2/B at all. Did you mean "could go for 2/B" there? /Andreas
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
