domenic at domenicdenicola.com (2013-08-19T04:59:26.967Z)
On 12 August 2013 18:52, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > 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).
On 12 August 2013 18:52, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > On Aug 12, 2013, at 2:22 AM, Andreas Rossberg wrote: >> On 10 August 2013 22:15, Brendan Eich <brendan at mozilla.com> 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 <allen at wirfs-brock.com> 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 >> > > >