You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 25, 2022. It is now read-only.
The Optional Chaining Operator allows a developer to handle many of those cases without repeating themselves and/or assigning intermediate results in temporary variables:
26
26
27
27
```javascript
28
-
var street =user.address?.street
29
-
var fooValue =myForm.querySelector('input[name=foo]')?.value
28
+
var street =user.address??.street
29
+
var fooValue =myForm.querySelector('input[name=foo]')??.value
30
30
```
31
31
32
32
The call variant of Optional Chaining is useful for dealing with interfaces that have optional methods:
33
33
34
34
```js
35
-
iterator.return?.() // manually close an iterator
35
+
iterator.return??() // manually close an iterator
36
36
```
37
37
or with methods not universally implemented:
38
38
```js
39
-
if (myForm.checkValidity?.() ===false) { // skip the test in older web browsers
39
+
if (myForm.checkValidity??() ===false) { // skip the test in older web browsers
40
40
// form validation fails
41
41
return;
42
42
}
@@ -54,44 +54,45 @@ The following languages have a similar feature. We haven’t checked whether the
54
54
55
55
## Syntax
56
56
57
-
The Optional Chaining operator is spelled `?.`. It may appear in three positions:
57
+
The Optional Chaining operator is spelled `??`. It may appear in three positions:
58
58
```javascript
59
-
obj?.prop// optional static property access
60
-
obj?.[expr] // optional dynamic property access
61
-
func?.(...args) // optional function or method call
59
+
obj??.prop// optional static property access
60
+
obj??[expr] // optional dynamic property access
61
+
func??(...args) // optional function or method call
62
62
```
63
63
64
-
### Notes
65
-
* In order to allow `foo?.3:0` to be parsed as `foo ?.3:0` (as required for backward compatibility), a simple lookahead is added at the level of the lexical grammar, so that the sequence of characters `?.` is not interpreted as a single token in that situation (the `?.` token must not be immediately followed by a decimal digit).
64
+
### Why two question marks instead of one?
65
+
66
+
An earlier version of this proposal used `??.` for the optional chaining operator, with `??[` for dynamic property access and `??(` for optional function/method calls. The switch to two question marks allows for more consistency and the ability to omit the surprising `.` in the latter two cases. See [the past discussion](https://github.com/tc39/proposal-optional-chaining/issues/34) on this topic for more details.
66
67
67
68
## Semantics
68
69
69
70
### Base case
70
-
If the operand at the left-hand side of the `?.` operator evaluates to undefined or null, the expression evaluates to undefined. Otherwise the targeted property access, method or function call is triggered normally.
71
+
If the operand at the left-hand side of the `??` operator evaluates to undefined or null, the expression evaluates to undefined. Otherwise the targeted property access, method or function call is triggered normally.
71
72
72
73
Here are basic examples, each one followed by its desugaring. (The desugaring is not exact in the sense that the LHS should be evaluated only once.)
73
74
```js
74
-
a?.b// undefined if `a` is null/undefined, `a.b` otherwise.
75
+
a??.b// undefined if `a` is null/undefined, `a.b` otherwise.
75
76
a ==null?undefined:a.b
76
77
77
-
a?.[x] // undefined if `a` is null/undefined, `a[x]` otherwise.
78
+
a??[x] // undefined if `a` is null/undefined, `a[x]` otherwise.
78
79
a ==null?undefined: a[x]
79
80
80
-
a?.b() // undefined if `a` is null/undefined
81
+
a??.b() // undefined if `a` is null/undefined
81
82
a ==null?undefined:a.b() // throws a TypeError if `a.b` is not a function
82
83
// otherwise, evaluates to `a.b()`
83
84
84
-
a?.() // undefined if `a` is null/undefined
85
+
a??() // undefined if `a` is null/undefined
85
86
a ==null?undefined:a() // throws a TypeError if `a` is neither null/undefined, nor a function
86
87
// invokes the function `a` otherwise
87
88
```
88
89
89
90
### Short-circuiting
90
91
91
-
If the expression on the LHS of `?.` evaluates to null/undefined, the RHS is not evaluated. This concept is called *short-circuiting*.
92
+
If the expression on the LHS of `??.` evaluates to null/undefined, the RHS is not evaluated. This concept is called *short-circuiting*.
92
93
93
94
```js
94
-
a?.[++x] // `x` is incremented if and only if `a` is not null/undefined
95
+
a??[++x] // `x` is incremented if and only if `a` is not null/undefined
In fact, short-circuiting, when triggered, skips not only the current property access, method or function call, but also the whole chain of property accesses, method or function calls directly following the Optional Chaining operator.
101
102
102
103
```js
103
-
a?.b.c(++x).d// if `a` is null/undefined, evaluates to undefined. Variable `x` is not incremented.
104
+
a??.b.c(++x).d// if `a` is null/undefined, evaluates to undefined. Variable `x` is not incremented.
104
105
// otherwise, evaluates to `a.b.c(++x).d`.
105
106
a ==null?undefined:a.b.c(++x).d
106
107
```
@@ -116,7 +117,7 @@ Let’s call *Optional Chain* an Optional Chaining operator followed by a chain
116
117
An Optional Chain may be followed by another Optional Chain.
117
118
118
119
```js
119
-
a?.b[3].c?.(x).d
120
+
a??.b[3].c??(x).d
120
121
a ==null?undefined:a.b[3].c==null?undefined:a.b[3].c(x).d
121
122
// (as always, except that `a` and `a.b[3].c` are evaluated only once)
@@ -138,7 +139,7 @@ Note that, whatever the semantics are, there is no practical reason to use paren
138
139
139
140
Because the `delete` operator is very liberal in what it accepts, we have that feature for free:
140
141
```js
141
-
delete a?.b
142
+
delete a??.b
142
143
// delete (a == null ? undefined : a.b) // that *would* work if `? :` could return a Reference...
143
144
a ==null?undefined:deletea.b// this is what we get, really
144
145
```
@@ -147,13 +148,13 @@ a == null ? undefined : delete a.b // this is what we get, really
147
148
148
149
The following are not supported due to a lack of real-world use cases:
149
150
150
-
* optional construction: `newa?.()`
151
-
* optional template literal: ``a?.`{b}```
152
-
* constructor or template literals in/after an Optional Chain: `newa?.b()`, ``a?.b`{c}```
151
+
* optional construction: `newa??()`
152
+
* optional template literal: ``a??`{b}```
153
+
* constructor or template literals in/after an Optional Chain: `newa??b()`, ``a??.b`{c}```
153
154
154
155
The following is not supported, although it has some use cases; see [Issue #18](//github.com/tc39/proposal-optional-chaining/issues/18) for discussion:
155
156
156
-
* optional property assignment: `a?.b= c`
157
+
* optional property assignment: `a??.b= c`
157
158
158
159
All the above cases will be forbidden by the grammar or by static semantics so that support might be added later.
159
160
@@ -165,28 +166,13 @@ All the above cases will be forbidden by the grammar or by static semantics so t
165
166
<dl>
166
167
167
168
168
-
<dt>obj?.[expr] and func?.(arg) look ugly. Why not use obj?[expr] and func?(arg) as does <language X>?
169
-
170
-
<dd>
171
-
172
-
We don’t use the `obj?[expr]` and `func?(arg)` syntax, because of the difficulty for the parser to efficiently distinguish those forms from the conditional operator, e.g., `obj?[expr].filter(fun):0` and `func?(x -2) +3:1`.
173
-
174
-
Alternative syntaxes for those two cases each have their own flaws; and deciding which one looks the least bad is mostly a question of personal taste. Here is how we made our choice:
175
-
176
-
* pick the best syntax for the `obj?.prop` case, which is expected to occur most often;
177
-
* extend the use of the recognisable `?.` sequence of characters to other cases: `obj?.[expr]`, `func?.(arg)`.
178
-
179
-
As for <language X>, it has different syntactical constraints than JavaScript because of <some construct not supported by X or working differently in X>.
180
-
181
-
182
-
183
-
<dt>Why does (null)?.b evaluate to undefined rather than null?
169
+
<dt>Why does (null)??.b evaluate to undefined rather than null?
184
170
185
171
<dd>
186
172
187
-
Neither `a.b` nor `a?.b` is intended to preserve arbitrary information on the base object `a`, but only to give information about the property `"b"` of that object. If a property `"b"` is absent from `a`, this is reflected by `a.b===undefined` and `a?.b===undefined`.
173
+
Neither `a.b` nor `a??.b` is intended to preserve arbitrary information on the base object `a`, but only to give information about the property `"b"` of that object. If a property `"b"` is absent from `a`, this is reflected by `a.b===undefined` and `a??.b===undefined`.
188
174
189
-
In particular, the value `null` is considered to have no properties; therefore, `(null)?.b` is undefined.
175
+
In particular, the value `null` is considered to have no properties; therefore, `(null)??.b` is undefined.
190
176
191
177
192
178
@@ -198,19 +184,19 @@ See [Issue #3 (comment)](https://github.com/tc39/proposal-optional-chaining/issu
198
184
199
185
200
186
201
-
<dt>In a?.b.c, if a.b is null, then a.b.c will evaluate to undefined, right?
187
+
<dt>In a??.b.c, if a.b is null, then a.b.c will evaluate to undefined, right?
202
188
203
189
<dd>
204
190
205
191
No. It will throw a TypeError when attempting to fetch the property `"c"` of `a.b`.
206
192
207
193
The opportunity of short-circuiting happens only at one time, just after having evaluated the LHS of the Optional Chaining operator. If the result of that check is negative, evaluation proceeds normally.
208
194
209
-
In other words, the `?.` operator has an effect only at the very moment it is evaluated. It does not change the semantics of subsequent property accesses, method or function calls.
195
+
In other words, the `??.` operator has an effect only at the very moment it is evaluated. It does not change the semantics of subsequent property accesses, method or function calls.
210
196
211
197
212
198
213
-
<dt>In a deeply nested chain like `a?.b?.c`, why should I write `?.` at each level? Should I not be able to write the operator only once for the whole chain?</dt>
199
+
<dt>In a deeply nested chain like `a??.b??.c`, why should I write `??.` at each level? Should I not be able to write the operator only once for the whole chain?</dt>
Copy file name to clipboardExpand all lines: spec.html
+20-30Lines changed: 20 additions & 30 deletions
Original file line number
Diff line number
Diff line change
@@ -22,7 +22,7 @@
22
22
<h1>Scope</h1>
23
23
<p>This is the spec text of the <ahref="https://github.com/tc39/proposal-optional-chaining/">Optional Chaining proposal</a> in ECMAScript. </p>
24
24
25
-
<p>For the syntax, we use the `?.` token, with a lookahead at the level of the lexical grammar that allows to discriminate between `a?.b` (optional chaining) and `a?.3:0` (conditional operator, whose meaning cannot be changed due to backward compatibility constraints).</p>
25
+
<p>For the syntax, we use the `??.` token. An earlier version of this proposal used `?.`</p>
26
26
27
27
<p>An <ahref="https://claudepache.github.io/es-optional-chaining/">early version of this proposal</a> used a Nil reference to express short-circuiting. This one is based on syntax only.</p>
0 commit comments