Existential operator (was: ||= is much needed?)

David Bruant bruant.d at gmail.com
Tue Jun 19 02:30:52 PDT 2012


What about a more generic operator that would be able to silently absorb 
any error?

     let greedy = obj.hints?.greedy;

would become:

     let greedy = silent obj.hints.greedy;

The semantic would be exactly the same.
The syntax is up to debate. Specifically, it would be nice to be able to 
silence a part of an expression.
What about a 'try' without a catch?

     let greedy = try obj.hints.greedy
     let greedy = try{ obj.hints.greedy } || 22;

This is currently forbidden (I think for 2 reasons, one being that a try 
must be followed by a catch or finally and the other that try/catch 
cannot be used as expressions)

This idea is partly inspired by typeof which silences ReferenceErrors, 
which I see as a feature YMMV.
It is also intended to make programs potentially more robust more 
easily. For instance, JSON.stringify can throw errors in the rare case 
of cyclic references. But very few people know that. To make a robust 
program using JSON.stringify, one would just need to turn:

     let s = JSON.stringify(o)

into

     let s = try{ JSON.stringify(o) } || DEFAULT_VALUE;

instead of the current:

     let s;
     try{
         s = JSON.stringify(o)
     }
     catch(e){
         // I don't care about the error anyway
         s = DEFAULT_VALUE;
     }

David

Le 18/06/2012 07:11, Brendan Eich a écrit :
> Sorry, meant to start a new thread for:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator
>
> As the Syntax section hints, we can't also adopt CoffeeScript's ?( 
> variant, which enables foo.bar?(args, go, here).baz and the like. The 
> C syntax heritage prevails.
>
> /be
>
> Brendan Eich wrote:
>> David Herman wrote:
>>> On Jun 15, 2012, at 5:57 PM, satyr wrote:
>>>
>>>> On Sat, Jun 16, 2012 at 4:33 AM, David Herman <dherman at mozilla.com 
>>>> <mailto:dherman at mozilla.com>> wrote:
>>>>
>>>>     As for null, I can see how there's confusion about whether to use
>>>>     null vs undefined, and so I can see why CoffeeScript would just
>>>>     try to blur the distinction between them.
>>>>
>>>>
>>>> Not just for blurring. Rejecting `null` is essential for 
>>>> CoffeeScript's "existence" due to `?.`, the soak/safe access operator.
>>>
>>> I think you could make a case for ?. defaulting for both but ?? 
>>> defaulting only undefined. The case goes something like this:
>>>
>>> - The purpose of ?? is to provide a default value when no value was 
>>> provided. The way to say "no value" in JavaScript is undefined.
>>>
>>> - The purpose of ?. is to fail soft when doing a property lookup. 
>>> Both null and undefined throw when doing a property lookup.
>>
>> Agreed. This is one choice, it's plausible because of the distinction 
>> between defaulting (which requires intentional passing of a "please 
>> default" sentinel value, or not passing a trailing actual argument) 
>> and soaking up null-or-undefined.
>>
>> Yes, we could make ?? and ??= do the same for null as for undefined. 
>> I'm not sure that's the right choice, but it's a choice. For 
>> foo.bar?.baz, though, the clearer choice is to avoid throwing, which 
>> means evaluating to undefined if foo.bar is missing (evaluates to 
>> undefined) *or* has a value not coercible to object type (null or 
>> undefined). See
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator
>>
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list