Has any equivalent feature for the nullish coalescing ?? and optional
chaining ?. operators been proposed to paper over the deficiencies of
the destructuring syntax with to null values?
If not, I think one should be proposed. For the entire right side of
the binding, an equivalent to the default parameter = operator but
which also works on nulls would do very nicely. Reusing a token that
already exists, it could even be the nullish coalescing ?? operator,
though I feel like it would look neater with for example ?= even
though that would add an extra token to parse.
Likewise, I feel like an equivalent to the optional chaining ?.
operator that permit you to leave parameters undefined if the argument
is null or undefined could be useful. For undefined we can at least
receive an undefined argument and not having it error out using
default parameter {prop}={}, but we cannot do that for null.
I'd like to at least be able to in my function contracts guarantee
that the destructuring part, which is honestly neither the caller's
responsibility (because they cannot change what happens when I
destructure in my parameter list) nor is it the function's
responsibility (because destructuring is supposed to abstract away the
setup so we don't need to do it in the function body), happens without
causing errors. Right now null is a big hole in that - no matter what
we do, the only solution is to move setup into the function body
itself, which is exactly what we have destructuring to avoid.
Hello!
Has any equivalent feature for the nullish coalescing ?? and optional
chaining ?. operators been proposed to paper over the deficiencies of
the destructuring syntax with regards to null values?
If not, I think one should be proposed. For the entire right side of
the binding, an equivalent to the default parameter = operator but
which also works on nulls would do very nicely. Reusing a token that
already exists, it could even be the nullish coalescing ?? operator,
though I feel like it would look neater with for example ?= even
though that would add an extra token to parse.
Likewise, I feel like an equivalent to the optional chaining ?.
operator that permit you to leave parameters undefined if the argument
is null or undefined could be useful. For undefined we can at least
receive an undefined argument and not having it error out using
default parameter {prop}={}, but we cannot do that for null.
I'd like to at least be able to in my function contracts guarantee
that the destructuring part, which is honestly neither the caller's
responsibility (because they cannot change what happens when I
destructure in my parameter list) nor is it the function's
responsibility (because destructuring is supposed to abstract away the
setup so we don't need to do it in the function body), happens without
causing errors. Right now null is a big hole in that - no matter what
we do, the only solution is to move setup into the function body
itself, which is exactly what we have destructuring to avoid.
--
David "liorean" Andersson
Hello!
Has any equivalent feature for the nullish coalescing ?? and optional chaining ?. operators been proposed to paper over the deficiencies of the destructuring syntax with to null values?
If not, I think one should be proposed. For the entire right side of the binding, an equivalent to the default parameter = operator but which also works on nulls would do very nicely. Reusing a token that already exists, it could even be the nullish coalescing ?? operator, though I feel like it would look neater with for example ?= even though that would add an extra token to parse.
Likewise, I feel like an equivalent to the optional chaining ?. operator that permit you to leave parameters undefined if the argument is null or undefined could be useful. For undefined we can at least receive an undefined argument and not having it error out using default parameter {prop}={}, but we cannot do that for null.
I'd like to at least be able to in my function contracts guarantee that the destructuring part, which is honestly neither the caller's responsibility (because they cannot change what happens when I destructure in my parameter list) nor is it the function's responsibility (because destructuring is supposed to abstract away the setup so we don't need to do it in the function body), happens without causing errors. Right now null is a big hole in that - no matter what we do, the only solution is to move setup into the function body itself, which is exactly what we have destructuring to avoid.
Hello! Has any equivalent feature for the nullish coalescing ?? and optional chaining ?. operators been proposed to paper over the deficiencies of the destructuring syntax with regards to null values? If not, I think one should be proposed. For the entire right side of the binding, an equivalent to the default parameter = operator but which also works on nulls would do very nicely. Reusing a token that already exists, it could even be the nullish coalescing ?? operator, though I feel like it would look neater with for example ?= even though that would add an extra token to parse. Likewise, I feel like an equivalent to the optional chaining ?. operator that permit you to leave parameters undefined if the argument is null or undefined could be useful. For undefined we can at least receive an undefined argument and not having it error out using default parameter {prop}={}, but we cannot do that for null. I'd like to at least be able to in my function contracts guarantee that the destructuring part, which is honestly neither the caller's responsibility (because they cannot change what happens when I destructure in my parameter list) nor is it the function's responsibility (because destructuring is supposed to abstract away the setup so we don't need to do it in the function body), happens without causing errors. Right now null is a big hole in that - no matter what we do, the only solution is to move setup into the function body itself, which is exactly what we have destructuring to avoid. -- David "liorean" Andersson