On 12 August 2013 18:52, Allen Wirfs-Brock <[email protected]> wrote: > On Aug 12, 2013, at 2:22 AM, Andreas Rossberg wrote: >> On 10 August 2013 22:15, Brendan Eich <[email protected]> wrote: >>> Pattern matching is more precise and flexible, and that's why we considered >>> changing destructuring (which uses the pattern subgrammar) to refutable from >>> irrefutable. Even now with destructuring irrefutable, patterns in catch >>> clauses, match statements/expressions, or other future forms would want the >>> same subgrammar, as much as possible -- but with refutability. >> >> I'm confused now. Was there an actual decision to go back to >> irrefutable matching? I don't see that in the meeting notes (just an >> argument that it would be future hostile, which I strongly agree >> with). > > As the meeting I reported that I had spend considerable time reviewing the > refutable matching strawman. it's unresolved issues, and the likely impart on > the specification relative to other high priority work items. My conclusion > was that is unlikely we could incorporate that strawman and still meet our > year end spec. completion goal. Instead, I proposed we stick with the > currently specified destructuring semantics with a couple slight modification > that I had previously described in a private email exchange with you (which > I've copied below).
As I said in my reply, I'm totally fine with what you describe in that mail. But correct me if I'm wrong, that _is_ refutable destructuring, isn't it? All you seem to drop is the optional irrefutable part (the '?' feature). That's why I am quite confused about Brendan's statement above. > The discussion that followed was mostly about future proofing and various > people trying to channel for you in that regard. The schedule issue was real > and there wasn't any particular push back on that. Based upon that > discussion, plan is to update the draft to match what what I described > below unless you have similar scale alternatives to suggest. OK, I am happy to hear that the plan is to adopt your suggestion as is (the meeting notes only list point 1, so that wasn't obvious). /Andreas > On Jul 17, 2013, at 3:00 AM, Andreas Rossberg wrote: > >> The essence of your suggestion is to defer the ? operator, is that >> correct? I'd be totally fine with that. I'd even be happy to drop it >> entirely. But keep in mind that we came up with it to make refutable >> matching acceptable to proponents of sloppy style. >> >> /Andreas >> >> On 17 July 2013 00:50, Allen Wirfs-Brock <[email protected]> wrote: >>> I've been looking at the possibility that that we may have to defer some >>> accepted ES6 proposal if we are going to make our end of year feature >>> complete spec. target. >>> >>> One of the proposal that is a candidate for deferral is >>> http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching >>> >>> This was a late addition. I've already spent significant time on >>> understanding it implications and feel that resolving open design issues and >>> properly integrate it into the spec. is likely to take more time than we can >>> afford right now. >>> >>> In addition to unresolved syntax and semantic issues mentioned in the Wiki >>> proposal, there are a number of semantic differences between patterns in >>> regular declarations, patterns in parameter lists, and patterns in the LHS >>> of assignment expressions that need to be work through in the spec. I'm >>> also worried that decisions we make here could potentially negatively impact >>> a future pattern switch statement if we don't also take that into account at >>> the same time. >>> >>> I thinking it may be better to introduce this form of pattern matching >>> (include the switch statement) as a complete unit in ES7 rather than trying >>> to get it into ES6. >>> >>> However, doing so will requires that the currently spec'ed destructuring be >>> made future proof. I think we can do that with a few simple changes to the >>> current spec: >>> >>> 1. No implicit conversion, for example the following all throw: >>> >>> let {a } = undefined; >>> let [x,...y] = "abc"; >>> (({x})=>x)(0); >>> let {a: {x}} = {a: false}; >>> >>> 2. unmatched property selectors in patterns throw: >>> >>> let {a} = {b:5}; //throws >>> let [a,b,c] = [0,1]; //throws >>> >>> 3. unless they have a default value provided: >>> >>> let {a=undefined} = {b:5}; //variable a initialized to undefined >>> let [a,b,c=2] = [0,1]; // a initialized to 0, b to 1, c to 2 >>> >>> These are simple changes to make to the existing spec. My sense is that they >>> preserve the primary desturcturing use cases (include default value >>> assignment, particularly for parameters) while leaving us positioned to add >>> ? and other extended pattern features in ES6+ >>> >>> What do you think? Would these changes to the existing spec. be enough to >>> future proof destructuring and enable patterns in the next round? >>> >>> Allen >> > > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
