d get the
guarantees you want. This is the same reason TypeScript exists, and
has gained such a following. TypeScript is to ECMAScript as refutable
destructuring is to Axel's proposal.
Again, this works except in a match construct, where failure
ript exists, and has
gained such a following. TypeScript is to ECMAScript as refutable
destructuring is to Axel's proposal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Actually, I think it'd be fantastic to have an easy way to communicate required
parameters in an options object. It's a fairly common pattern; for example in
the S3 library knox that I maintain we require bucket, key, and secret, but
everything else has defaults.
___
On 8/16/2013 12:56 PM, Allen Wirfs-Brock wrote:
However, I think throwing is like to reveal bugs that might otherwise
be missed prior to deployment and as a code reader I would prefer to
encounter
let {x=undefined) = {};
which communicates much more clearly that there is an expectation that
On Aug 16, 2013, at 12:18 PM, Dmitry Soshnikov wrote:
> On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith wrote:
>
> And for the strict match one could introduce match(...) function which
> already would throw providing exactly matching procedure first, and then
> destructuring as a consequence.
On Fri, Aug 16, 2013 at 12:38 PM, Kevin Smith wrote:
>
>
> Do you not think that it would be awkward to have the exact same pattern
>>> syntax for these two cases (matching and destructuring), but with different
>>> semantics?
>>>
>>>
>> Yes, I don't think so.
>>
>
> Hmmm... Let me rephrase. It
> Do you not think that it would be awkward to have the exact same pattern
>> syntax for these two cases (matching and destructuring), but with different
>> semantics?
>>
>>
> Yes, I don't think so.
>
Hmmm... Let me rephrase. It would be awkward and confusing to have
divergent semantics for the s
On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith wrote:
>
>> And for the strict match one could introduce match(...) function which
>> already would throw providing exactly matching procedure first, and then
>> destructuring as a consequence.
>>
>
> Do you not think that it would be awkward to have
>
>
> And for the strict match one could introduce match(...) function which
> already would throw providing exactly matching procedure first, and then
> destructuring as a consequence.
>
Do you not think that it would be awkward to have the exact same pattern
syntax for these two cases (matching
rticipated in the conversation, felt that refutable
> destructuring was a mistake, but that we couldn't really come to any
> conclusions without Brendan and Andreas there, since the two of them had
> championed refutable destructuring.
> >
> > IOW, we don't have consensus a
On Aug 15, 2013, at 9:27 PM, David Herman wrote:
> This is *not* what I remember of the conversation, at all.
>
> My understanding was that pretty much everyone in the room, at least those
> who participated in the conversation, felt that refutable destructuring was a
> mista
>
> My understanding was that pretty much everyone in the room, at least those
> who participated in the conversation, felt that refutable destructuring was
> a mistake,
Can you elaborate, please? Why?
{ Kevin }
___
es-discuss mailing lis
On Aug 15, 2013, at 9:27 PM, David Herman wrote:
> we couldn't really come to any conclusions without Brendan and Andreas there
My mistake, Brendan was there. It was only Andreas who wasn't there.
Dave
___
es-discuss mailing list
es-discuss@mozilla.o
standing was that pretty much everyone in the room, at least those who
participated in the conversation, felt that refutable destructuring was a
mistake, but that we couldn't really come to any conclusions without Brendan
and Andreas there, since the two of them had championed refutable
On Tuesday, August 13, 2013, Allen Wirfs-Brock wrote:
>
> On Aug 13, 2013, at 2:31 PM, Brendan Eich wrote:
>
> > Andreas Rossberg wrote:
> >> As I said in my reply, I'm totally fine with what you describe in that
> >> mail. But correct me if I'
Allen Wirfs-Brock wrote:
On Aug 13, 2013, at 2:31 PM, Brendan Eich wrote:
Andreas Rossberg wrote:
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
On Aug 13, 2013, at 2:31 PM, Brendan Eich wrote:
> Andreas Rossberg wrote:
>> 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 i
Andreas Rossberg wrote:
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
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'
On Aug 12, 2013, at 2:22 AM, Andreas Rossberg wrote:
> On 10 August 2013 22:15, Brendan Eich 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 destruc
On 10 August 2013 22:15, Brendan Eich 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 state
On Fri, Aug 9, 2013 at 11:52 PM, Brendan Eich wrote:
> Rick Waldron wrote:
>
>> My argument was specifically about the current meaning of the ascii
>> exclamation "!" and that assigning it an additional context-based meaning
>> that's quite the opposite of the current unary operator meaning,
>>
>
ES4 had this as "like" (at one point "is like"):
(arg1 like MyClass)
How deep this goes is one design decision; there are lots of others.
Pattern matching is more precise and flexible, and that's why we
considered changing destructuring (which uses the pattern subgrammar) to
refutable from ir
It looks to me like there are people who want a sort of ducktypeof operator.
arg1 ducktypeof MyClass
Which would return true if the shape of arg1 where the same as MyClass. If
I wanted to write as a refutable pattern I could end up with a large block
that may be repeated in several class methods.
Rick Waldron wrote:
My argument was specifically about the current meaning of the ascii
exclamation "!" and that assigning it an additional context-based
meaning that's quite the opposite of the current unary operator meaning,
Ok, and I'm with you (recall Mark M. wants ! as restricted-producti
On 8/9/2013 5:45 PM, Allen Wirfs-Brock wrote:
and if we make U+2639 a special token that evaluated to throw TypeError we
could say
function foo( {a=☹ }) {}
This would be awesome.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.moz
On Aug 9, 2013, at 5:37 PM, Allen Wirfs-Brock wrote:
>
> On Aug 9, 2013, at 4:21 PM, Brandon Benvie wrote:
>
>> On 8/9/2013 4:03 PM, Allen Wirfs-Brock wrote:
>>> const MUST = () => {throw TypeError("Missing required parameter"};
>>>
>>> function foo (a=MUST(), b, c) {...}
>>
>> But that doesn
On Aug 9, 2013, at 4:21 PM, Brandon Benvie wrote:
> On 8/9/2013 4:03 PM, Allen Wirfs-Brock wrote:
>> const MUST = () => {throw TypeError("Missing required parameter"};
>>
>> function foo (a=MUST(), b, c) {...}
>
> But that doesn't work for:
>
> ```js
> function foo({ a } = { a: MUST() }){}
th
On 8/9/2013 4:03 PM, Allen Wirfs-Brock wrote:
const MUST = () => {throw TypeError("Missing required parameter"};
function foo (a=MUST(), b, c) {...}
But that doesn't work for:
```js
function foo({ a } = { a: MUST() }){}
foo({}); // doesn't throw
function bar({ +a }){}
bar({}); // would throw
On Fri, Aug 9, 2013 at 6:40 PM, Brendan Eich wrote:
> On Aug 9, 2013, at 3:32 PM, Rick Waldron wrote:
>
> On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer wrote:
>
>> AFAICT, there is no current consensus on whether destructuring assignment
>> is refutable by default or not:
>>
>> https://githu
On Aug 9, 2013, at 2:58 PM, Domenic Denicola wrote:
> Woah. I was sad about the loss of refutable destructuring, i.e. I would
> rather have had it by default, but this idea is a pretty brilliant way to
> make lemonade out of lemons. I would *love* a way to declaratively specify
&
On Aug 9, 2013, at 3:32 PM, Rick Waldron wrote:
> On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer wrote:
>> AFAICT, there is no current consensus on whether destructuring assignment is
>> refutable by default or not:
>> https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-07/july-23.md#44
On 8/9/2013 3:36 PM, Axel Rauschmayer wrote:
let { +a: foo, b: bar } = { a: 1 }; // foo = 1, b = undefined
let { +a: foo, b: bar } = { }; // exception
function bla(+mandatoryArg, optionalArg1, optionalArg2 = 123) {
...
}
I presume these would also be valid, and do the
> While I agree this is interesting and should be explored further, I reject
> the proposal to add more meaning to the "!" character. Given this proposal,
> "!" would sometimes mean "not" or "negate" (as in it's current form) and
> sometimes mean "a required thing". Meanwhile, "refute" is a syno
On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer wrote:
> AFAICT, there is no current consensus on whether destructuring assignment
> is refutable by default or not:
>
> https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-07/july-23.md#44-consider-deferring-es6-refutable-matching
>
> Could
Woah. I was sad about the loss of refutable destructuring, i.e. I would rather
have had it by default, but this idea is a pretty brilliant way to make
lemonade out of lemons. I would *love* a way to declaratively specify required
parameters.
___
es
AFAICT, there is no current consensus on whether destructuring assignment is
refutable by default or not:
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-07/july-23.md#44-consider-deferring-es6-refutable-matching
Could we make destructuring assignment fail soft and introduce a marker fo
37 matches
Mail list logo
