Discuss
  • Existential Operator / Null Propagation Operator (Laurentiu Macovei)

Existential Operator / Null Propagation Operator (Laurentiu Macovei)

# Ron Waldon (9 years ago)

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:

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> wrote:

---------- Forwarded message ---------- From: Laurentiu Macovei <laurentiu.macovei at gmail.com>

To: Sander Deryckere <sanderd17 at gmail.com>

Cc: "es-discuss@ <es-discuss at mozilla.org>mozilla.org <es-discuss at mozilla.org> list" <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 Microsoft/TypeScript#16:// Microsoft/TypeScript#16github.com, Microsoft/TypeScript#16/Microsoft/ Microsoft/TypeScript#16TypeScript Microsoft/TypeScript#16/issues/16 Microsoft/TypeScript#16

Is there a better place to propose it for ES6/ES7 ?

This would be amazing operator!! Especially for ES6/ES7/TypeScript


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:


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.


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)

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.
  1. Should work since it understands that is not a number calling a property from Number.prototype

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:


var correct1 = x..[1]..y; //would work returning 'test'

var correct2 = x..[2]..y; //would work returning undefined;

What do you think folks?

Best ,

Laurenţiu Macovei

# Steve Fink (9 years ago)

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.

# Laurentiu Macovei (9 years ago)

Ron,

Javascript only works by assumptions, that the developer made at the time the code was written than at runtime they will be the same (and not changing by newly ESX).

So, it does NOT make sense to change the code that currently works (expecting to throw error) so that would silently return null or undefined The behavior of the code would change and perhaps over 90% of the existing libraries would not work anymore.

By wrapping code in try / catch is actually even worse - as adds way extra code and extra penalty in performance. Exceptions should not be used for anything but exception-edge cases.

So I presume the answer to your proposals is no and no.

And btw, the ?. is already available in languages like Groovy, Swift and proposed for c# 6.0. Even Ruby has a proposal for the opposite one .? doing the same thing.

However as I have clarified above var result = condition ? a?.b?.c?.d : a?.x?.c?.d; is way unclear / worse, in my opinion, than var result = condition ? a..b..c..d : a..x..c..d;

Best , Laurenţiu Macovei DotNetWise

# Isiah Meadows (9 years ago)

I strongly oppose. I already write a ton of code that relies on that throwing, using that for testing purposes. I'd rather something throw violently than to silently fail in an unexpected, potentially seemingly unrelated place. Not even pure functional programming can act as a safety net for implicit undefined/null access.