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
Basically a[^i] should have very same behavior to a[i] (except it calculate index from the end), but we need to consider how to handle non-index case. For a[i], it just use i as property, or in some cases (eg. TypedArray), it fallback to property semantic for non-index cases. ^i always represent index, so if it failed to calculate index, should it and how it could be fallback to normal property?
Here are the non-index (and out-of-range) cases:
a is not an Array-like, ie. Number(a.length) is NaN.
i is not a numeric, ie. Number(i) is NaN.
i is not an integer
i is negative
i is greater than a.length
// not Array-likeletx={0: 0,1: 1,'-1': -1}x[^1]// ?x[^1]='^1'// what will happen?// other casesletx=[1,2,3]letv="not-numeric"// or 0.5 (not integer), -1 (negative), 10 (> x.length)x[^v]// ?x[^v]="?"// ?
Here are some possible options:
A. Always throw TypeError/RangeError for non-index/out-of-range cases
B. For Get operation, just return undefined, for Set operation, silent failure
C. For Get operation, just return undefined, for Set operation, throw TypeError/RangeError
D. For Get operation, just return undefined, for Set operation, throw TypeError/RangeError in strict mode, silent failure in non-strict mode
E. Same as A in strict mode, same as B in non-strict mode
F. Pure syntax sugar, aka. use the exact semantic of a[a.length - i] (though only access a and a.length once)
G. Use the similar semantic of Array methods (eg. at(), slice())
H. Some other behavior?
My preferences is E = D > A = B = C >> F >> G.
A seems too rigor, F seems too loose (easy to introduce unexpected result or effect, eg. might add NaN property on a in Set case), G is actually not the option, just for comparison.
The text was updated successfully, but these errors were encountered:
Basically
a[^i]
should have very same behavior toa[i]
(except it calculate index from the end), but we need to consider how to handle non-index case. Fora[i]
, it just usei
as property, or in some cases (eg.TypedArray
), it fallback to property semantic for non-index cases.^i
always represent index, so if it failed to calculate index, should it and how it could be fallback to normal property?Here are the non-index (and out-of-range) cases:
a
is not an Array-like, ie.Number(a.length)
isNaN
.i
is not a numeric, ie.Number(i)
isNaN
.i
is not an integeri
is negativei
is greater thana.length
Here are some possible options:
A. Always throw TypeError/RangeError for non-index/out-of-range cases
B. For
Get
operation, just returnundefined
, forSet
operation, silent failureC. For
Get
operation, just returnundefined
, forSet
operation, throw TypeError/RangeErrorD. For
Get
operation, just returnundefined
, forSet
operation, throw TypeError/RangeError in strict mode, silent failure in non-strict modeE. Same as A in strict mode, same as B in non-strict mode
F. Pure syntax sugar, aka. use the exact semantic of
a[a.length - i]
(though only accessa
anda.length
once)G. Use the similar semantic of Array methods (eg.
at()
,slice()
)H. Some other behavior?
My preferences is E = D > A = B = C >> F >> G.
A seems too rigor, F seems too loose (easy to introduce unexpected result or effect, eg. might add
NaN
property ona
inSet
case), G is actually not the option, just for comparison.The text was updated successfully, but these errors were encountered: