Precedence

[littledan]

The current draft spec gives ?? precedence and parsing in general exactly equal to ||. I wrote the spec this way because I was imagining people upgrading code from || to ??, and thought that the parsing shouldn't change. However, maybe a lower precedence would make more sense, to be "the lowest expression precedence". Any opinions?

[ljharb]

Can you provide some code examples that would behave differently with this change?

[littledan]

x ?? y || z would bracket as (x ?? y) || z currently (as if ?? were ||), or x ?? (y || z) with a change to a lower precedence (with the logic that ?? is the default operator, not involved in calculations as || is).

[ljharb]

What would be the motivation? The current precedence seems sensible to me as it allows for LTR reading; the latter seems like a footgun.

[littledan]

The motivation would be that || as a default operator is just weird tradition, and really, you should be able to use any other kind of expression as the arguments. I don't really see why either would be a terrible footgun; I can imagine people being tripped up either way it's decided.

[jridgewell]

Mine is mainly it feels weird that && and || don't bind the same (which can't change for legacy reasons). But now it's even more apparent because of the third logical operator ??:

x ?? y || z === (x ?? y) || z
x ?? y && z === x ?? (y && z)

Both versions of y OP z feel like the right hand size to me.

[claudepache]

Here are what some other languages use for the precedence of ??:

Between || and ? :

• C#: https://msdn.microsoft.com/en-us/library/6a71f45d.aspx
• PHP: http://php.net/manual/en/language.operators.precedence.php

Same level as || — but with some associativity rule I’m not sure to correctly guess (my guess is that the evaluation of the expression would stop as soon as short-circuiting occurs somewhere):

• Perl6: https://docs.perl6.org/language/operators (the operator is spelled //)

Higher precedence than comparison operators:

• Swift: https://developer.apple.com/documentation/swift/operator_declarations

[claudepache]

I wrote the spec this way because I was imagining people upgrading code from || to ??, and thought that the parsing shouldn't change.

If we want to preserve expectation (rather than parsing), we must give ?? a lower precedence than || (as C# does). Indeed, consider:

a || b || c    // equivalent to: a ? a : b ? b : c
(a || b) || c  // ditto
a || (b || c)  // ditto

The expectation is: the first of a, b or c that is not falsy. Note that grouping parentheses, although changing the parsing, does not change the result.

Compare with:

a ?? b || c   // expection: a != null ? a : b ? b : c
(a ?? b) || c // equivalent to: a != null ? (a ? a : c) : b ? b : c
a ?? (b || c) // equivalent to: a != null ? a : b ? b : c

The expectation is: the first of a, b or c that is not nully (if followed by ??) resp. falsy (if followed by ||).

The issue is that “a is not nully” is strictly weaker than “a is not falsy”, and we should give the former condition more weight by assigning to ?? a lower precedence than ||.

---

On the other hand, my experience of that operator in PHP shows that a higher precedence than comparison operators (à la Swift) is probably what is wanted when seeking to minimise the use of parentheses; because I write often something similar to:

if (($expression ?? 'default') === 'value') { ... }

---

My conclusion is:

• If we want to minimise hazards when people upgrade their code, we should pick C# semantics.
• If we want to minimise the need of parentheses, Swift semantics may be interesting.

[ljharb]

Since switching to ?? from || will always be hazardous unless the dev knows the LHS is either truthy or nullish, I'm not sure we'd be minimizing hazards with either approach - which is why i think I lean towards swift semantics.

[littledan]

The issue is that “a is not nully” is strictly weaker than “a is not falsy”, and we should give the former condition more weight by assigning to ?? a lower precedence than ||.

I don't really understand this "strictly weaker" idea. If you have a chain of ?? and || mixed together, doesn't it make sense to treat them linearly? The distinction is just about how you treat the immediately preceding operand, but the logic to fall to the next one is the same. For this reason, I'm increasingly convinced that keeping the same precedence is the right option.

[rattrayalex]

I'm curious; what's the current thinking here? Undecided?

[littledan]

We previously decided on giving ?? the same precedence as ||; you can see this in the current draft specification. However, @waldemarhorwat is expressing concerns in #26, so we might reconsider.

[rattrayalex]

Thanks! Looks like the summary quote is:

If ?? has lower precedence than ||, then the semantics of a ?? b || c would be a ?? (b || c)

With that being desired behavior (I think I agree fwiw).

[ljharb]

So between "lower" and "same", does that mean that the following holds for a ?? b || c?

	nullish a	non-nullish a
lower: a ?? (b || c)	b || c	a
same: (a ?? b) || c	b || c	a || c