Existential Operator / Null Propagation Operator (Laurentiu Macovei)

[Steve Fink]

Uh, isn't that a pretty large compatibility risk?

<input type='checkbox' onclick='doUntestedStuff(tihs.checked)'>

You're suddenly calling doUntestedStuff() where before it was harmlessly 
erroring.


On 10/29/2015 12:30 PM, Ron Waldon wrote:
>
> Has anyone considering just making dot-property access return 
> intermediate undefined or null values by default?
>
> Not having to introduce new syntax would be a bonus. I'm trying to 
> think of existing code that this would break and can't think of any 
> good examples.
>
> The only compatibility issue I have thought of so far is code that 
> relies on an Error being thrown but also does not check the value:
>
> ```js
> let value;
> try { value = deep.deep.deep.prop; } catch (err) { /* ... */ }
> // use value without even a basic truthy test
> ```
>
> On Fri, 30 Oct 2015, 06:07  <es-discuss-request at mozilla.org 
> <mailto:es-discuss-request at mozilla.org>> wrote:
>
>
>     ---------- Forwarded message ----------
>     From: Laurentiu Macovei <laurentiu.macovei at gmail.com
>     <mailto:laurentiu.macovei at gmail.com>>
>     To: Sander Deryckere <sanderd17 at gmail.com
>     <mailto:sanderd17 at gmail.com>>
>     Cc: "es-discuss@ <mailto:es-discuss at mozilla.org>mozilla.org
>     <mailto:es-discuss at mozilla.org> list" <es-discuss at mozilla.org
>     <mailto:es-discuss at mozilla.org>>
>     Date: Thu, 29 Oct 2015 19:52:37 +0100
>     Subject: Re: Re: Existential Operator / Null Propagation Operator
>
>     Yes! I have updated my answer using markdown and also posted on
>     the original issue of TypeScript. https
>     <https://github.com/Microsoft/TypeScript/issues/16>://
>     <https://github.com/Microsoft/TypeScript/issues/16>github.com
>     <https://github.com/Microsoft/TypeScript/issues/16>/Microsoft/
>     <https://github.com/Microsoft/TypeScript/issues/16>TypeScript
>     <https://github.com/Microsoft/TypeScript/issues/16>/issues/16
>     <https://github.com/Microsoft/TypeScript/issues/16>
>
>     Is there a better place to propose it for `ES6`/`ES7` ?
>
>     This would be amazing operator!! Especially for
>     `ES6`/`ES7`/`TypeScript`
>
>     ```js
>
>     var error = a.b.c.d; //this would fail with error if a, b or c are
>     null or undefined.
>
>     var current = a && a.b && a.b.c && a.b.c.d; // the current messy
>     way to handle this
>
>     var currentBrackets = a && a['b'] && a['b']['c'] &&
>     a['b']['c']['d']; //the current messy way to handle this
>
>     var typeScript = a?.b?.c?.d; // The typescript way of handling the
>     above mess with no errors
>
>     var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of
>     handling the above mess with no errors
>
>     ```
>
>     However I propose a more clear one - as not to confuse ? from the
>     a ? b : c statements with a?.b statements:
>
>     ```js
>
>     var doubleDots = a..b..c..d; //this would be ideal to understand
>     that you assume that if any of a, b, c is null or undefined the
>     result will be null or undefined.
>
>     var doubleDotsWithBrackets = a..['b']..['c']..['d'];
>
>     ```
>
>     For the bracket notation, I recommend two dots instead of a single
>     one as it's consistent with the others when non brackets are used.
>     Hence only the property name is static or dynamic via brackets.
>
>     Two dots, means if its null or undefined stop processing further
>     and assume the result of expression is null or undefined. (as d
>     would be null or undefined).
>
>     Two dots make it more clear, more visible and more space-wise so
>     you understand what's going on.
>
>     This is not messing with numbers too - as is not the same case e.g.
>
>     ```js
>
>     1..toString(); // works returning '1'
>
>     var x = {};
>
>     x.1 = {y: 'test' }; //fails currently
>
>     x[1] = {y: 'test' }; //works currently
>
>     var current = x[1].y; //works
>
>     var missing= x[2].y; //throws exception
>
>     var assume= x && x[2] && x[2].y; // works but very messy
>
>     ```
>
>     About numbers two options: Your call which one can be adopted, but
>     I recommend first one for compatibility with existing rules!
>
>     1. Should fail as it does now (`x.1.y` == `runtime error`)
>
>     ```js
>
>     var err = x..1..y; // should fail as well, since 1 is not a good
>     property name, nor a number to call a method, since it's after x
>     object.
>
>     ```
>
>     2. Should work since it understands that is not a number calling a
>     property from `Number.prototype`
>
>     ```js
>
>     var err = x..1..y; // should work as well, resulting 'test' in
>     this case
>
>     var err = x..2..y; // should work as well, resulting undefined in
>     this case
>
>     ```
>
>     With dynamic names:
>
>     ```js
>
>     var correct1 = x..[1]..y; //would work returning 'test'
>
>     var correct2 = x..[2]..y; //would work returning undefined;
>
>     ```
>
>     What do you think folks?
>
>     Best Regards,
>
>     Laurenţiu Macovei
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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