Existential operator

[David Bruant]

Le 19/06/2012 11:40, Hemanth H.M a écrit :
> As there is no keyword as 'or' so far, does something like *x = 
> x.value or 5 *sound better?
I realize I gave examples with default values in case of error, but it 
doesn't have to be the case. Specifically in

     let greedy = try obj.hints.greedy

an "or" statement would be cumbersome since there is already 'undefined' 
as implicit or-value.
But why not.

David


>
> On Tue, Jun 19, 2012 at 3:00 PM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     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>
>                     <mailto: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 <mailto:es-discuss at mozilla.org>
>             https://mail.mozilla.org/listinfo/es-discuss
>
>         _______________________________________________
>         es-discuss mailing list
>         es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>         https://mail.mozilla.org/listinfo/es-discuss
>
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> -- 
> /'I am what I am because of who we all are'/
> h3manth.com <http://www.h3manth.com>
> /-- Hemanth HM/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120619/85062308/attachment-0001.html>