Change operator to ||| and reserve ?? for optional chaining

[dfahlander]

As the form x || defaultValue is a widely known pattern for javascript developers, a natural and more intuitive operator for this proposal would therefore rather be ||| (three pipe-signs instead of two). This goes in line with the relation between the === and == operators.

Going this direction would also also free up the ?? operator to be used for optional chaining, which is discussed here

Sample

function foo(options) {
   return options??.myOption ||| "defaultValue";
}

[gisenberg]

||| implies "stricter OR", which folks might assume to work with null, undefined and false, so the intuitive behavior would be unusual for null coalescing.

I'm floating this syntax option with the committee today, so we'll see.

[hax]

If use ||| then there is no reason (so called "consistency of 4 operators" 🙃) to keep use ??. ??[] ??().

[ljharb]

@hax the 3 optional chaining operators will always need to be consistent within themselves.

[rattrayalex]

FWIW I would intuit ||| to mean something closer to "if LHS is === false, then RHS".

The ?? proposal for optional chaining explicitly intended for this proposal to end up with something like ??| or ??:, IIRC.

[hax]

@ljharb I know. I just point out that the only reason someone prefer ?? than all ?> ?& ... alternatives which also have "consistency of 3" is so called "consistency of 4" (Though IMO it's no sense). So if you choose ||| then this questionable reason is also gone.

[ljharb]

That’s not the only reason; aesthetics and overloaded meanings come into play as well.

[hax]

@ljharb Yeah I believe there are always other reasons. But it seems in previous discussions "the other reasons" for "??." were not mentioned much. Maybe I missed some.

In fact I always try to find the real reasons behind aesthetics, include ??. option, for example double question mark solution could keep the operator only use two distinct char which is good for ergonomics. But I hope if we use a more objective reason like that, we also need to accept using the same criteria to check the bad part of it, like ??. is too close with ??: which harmful to ergonomics.

[selipso]

Yes! I was just thinking this independently, especially in light of tc39/proposal-optional-chaining#48

I'm glad someone else has already thought of this. It also gives the language enough syntax flexibility to add maybe a nullish and operator (&&&) that has equally intuitive syntax (accepts 0 and '' as truth values)

[Mouvedia]

In the same way that ||= and &&= will be introduced together, ||| and &&& come in pair.

[ljharb]

Repeating my comment here:

in the TC39 meeting this week it was brought up that if === is a stricter ==, then ||| would be a stricter ||, and since || deals with truthiness, ||| would need to deal with true - a compelling argument that seemed to convince many people that ||| is not an option for this proposal.

[selipso]

Repeating my response here about the word 'stricter' not being a comprehensive enough definition from one data point. This is still the best and most intuitive syntax by a long shot. Fewer keystroke, less characters to remember, easier to learn, easier to understand.

Then by that logic ||| is 'stricter' than || because nullish types are more limiting than the loosey-goosey || where !(0 || '') === true. Perfectly intuitive to me and easily explainable to even my high school students that I teach programming to.

Since we have only one point of reference for this syntax (== vs ===) I don't think 'stricter' is the right word for it but rather a "restriction of scope" in the underlying values comparison. We are essentially restricting scope by adding a third character in both cases.

With == vs === we are restricting scope to exact matches of the underlying data type. With || vs ||| we are restricting scope from "falsy" values to only null and undefined values.

original source: tc39/proposal-optional-chaining#48 (comment)

[Mouvedia]

What matters is whether the couple &&&/||| is useful or not; if both are then it's a big + in favor of |||.

[claudepache]

In my PHP codebase, I have some occurrences of $options[‘foo’] ?? false and $options[‘bar’] ?? true, and I am happy that they didn’t pick |||...

[hax]

Repeating my comment here:

I think we should learn from failure of visually too close operators. The mainstream coding style now only allow === and forbidden == to avoid the confusion and accidently typos, there is also a rule which forbidden | and & to avoid potential confusion/typo with || and &&, so it's hard to convince the community adding ||| (and adding &&& for consistency) would be a good idea.

Note we can forbidden == because all == use cases could be converted to === with explicit type cast. We can forbidden & and | because most modules do not need bitwise operations, and we can choose to opt in if we really need bitwise ops in special modules. But we can't forbidden || because it's very correct to use || as logical operator, both || and ||| have very common use cases. This is why we need null coalescing operator, and I think as the motivation of some linter rules suggest, we'd better use syntax which have enough distance to avoid the confusion and typo.

[lazarljubenovic]

I don't understand the rationale for ||| being used forsomething called nullish coelascing. We use x || 'default' simply because we don't really have other one-line options. We don't want to make || stricter, we want an actual operator which we can use for this use-case.

A stricter || would mean that it only "accepts" true, not that it only "accepts" null and undefined. Nullish coelascing shouldn't contain any character which signalizes that it's an operator which deals with truthiness or booleans (|, &), because it doesn't.

[ljharb]

This seems answered; the feature is stage 4; I think this can be closed.