Consider if this feature is worth implementing

[damaon]

From my experience in coffeescript ? operator isn't great idea. YMMW.

1. Inexperienced people tend to use it even when it's not needed and in the process you lose data schema information.

2. Also abuse of it happens when there's some problems with async code / data loading.

So I think it's not good to make it more ergonomic to mask mistakes with syntax sugar. Just an opinion.

[dannyskoog]

Abuse of (or inexperience with) particular syntax isn’t good enough argument for not delivering it to the remaining mass that plan to use it as it’s intended to, IMO

[rinick]

I think most inexperienced developers would forget to check null value, rather than abusing the ?. operator, so they need this feature.

[claudepache]

From my experience in coffeescript ? operator isn't great idea. YMMW.

1. Inexperienced people tend to use it even when it's not needed and in the process you lose data schema information.
2. Also abuse of it happens when there's some problems with async code / data loading.

So I think it's not good to make it more ergonomic to mask mistakes with syntax sugar. Just an opinion.

Sure, adding a random ”if not null” test before understanding why null did occur at this point is a bad habit. However:

• This is not a problem specific to this feature: it is a general problem, with many variants like: coerce to string when an unexpected non-string occurs, or: use the try-with-empty-catch pattern when an unexpected TypeError occurs.

• The problem is better solved by education, as it is better for a programmer to understand why they should not do that, than to try to do what they should not. (They could even succeed in doing unergonomically what they should not, and the outcome would be even worse.)

[vflash]

it is best if this is the default behavior.
console.log(typeof (null).aaa.bbb.ccc) // undefined
clear and beautiful

[claudepache]

@vflash

it is best if this is the default behavior.
console.log(typeof (null).aaa.bbb.ccc) // undefined
clear and beautiful

That would be a major change of the semantics of property access, and a change that we don’t intend to make in the scope of this proposal. If you do think it is worth, you may discuss it on the es-discuss mailing list (but personally I doubt that it will please many people).

[vflash]

This is a necessary feature. But I don't like the look of the code.
aaa?.bbb?.ccc?.ddd?.eee
There's a lot of garbage. The appearance of the code is worth paying attention to.

null.aaa.bbb.ccc // ideal
null?.aaa.bbb.ccc // for example compromise

[ljharb]

@vflash your "ideal" is impossible as that would break tons of code; your "compromise" wouldn't allow for some of those property accesses to be optional intermixed with normal/required ones.

[vflash]

@ljharb

your "compromise" wouldn't allow for some of those property accesses to be optional intermixed with normal/required ones.

var bb = null?.aa.bb;
var cc = bb.cc;
or
(null?.aa.bb).cc

your "ideal" is impossible as that would break tons of code

Is there research on this topic ?

[ljharb]

@vflash I personally have libraries that rely on the error produced from property-accessing into null or undefined; i'm sure research could be done, but I'm not sure anyone would consider it worth it to do research so that we could magically change the semantics of the last 20+ years of javascript property access.

[hpoul]

@vflash

There's a lot of garbage. The appearance of the code is worth paying attention to.

it should very much be the exception that you need a null-safe operator.. if you have no idea how your data looks 3 levels deep it might be worth reconsidering your data structures. Usually it is better to fail early, so it's more than debatable whether your "ideal" variant is really a good idea imho...

[vflash]

@ljharb You can't make an omelette breaking eggs. ("use strict"; ~~ 10 years, "with(x) {...}" )
@hpoul Better when the code does not fall

[dantman]

@ljharb You can't make an omelette breaking eggs.

We're not making an omelette. We're standardizing a language, and those "eggs" want to break may be live websites people depend on.

@hpoul Better when the code does not fall

He said fail early. When you blindly add "safe" operators to everything, the most common occurrence is not that the code just starts working; the most common occurrence is that you get a different error a few lines or function calls later and then spend hours trying to track down the real bug.

[ljharb]

@vflash there does not exist a feature that is worth breaking the web, and again, your "ideal" is something i'd find extremely worse than what we have now (ie, it's much more implicit, which increases confusion and the likelihood of bugs).

[claudepache]

@vflash

This is a necessary feature. But I don't like the look of the code.
aaa?.bbb?.ccc?.ddd?.eee
There's a lot of garbage. The appearance of the code is worth paying attention to.

This is partly because I pay attention to the appearance of my code, that I have initiated this proposal. Compared to what you have to do today, e.g.:

aaa && aaa.bbb && aaa.bbb.ccc && aaa.bbb.ccc.ddd && aaa.bbb.ccc.ddd.eee
// or
aaa && (_ = aaa.bbb) && (_ = _.ccc) && (_ = _.ddd) && _.eee

or something less hackish but considerably longer (a stack of if clauses), the code aaa?.bbb?.ccc?.ddd?.eee is really stylish...

[claudepache]

Closing this issue, as this feature is indeed considered worth implementing by the vast majority, per the various arguments given in this thread.

[claudepache]

@vflash As a side note, if you still find that aaa?.bbb?.ccc?.ddd?.eee contains too much grawlix, see #82 (comment).