Re: Default values for nulls
I'd find it more readable to allow an assignment operator, with the
semantic "do this transformation, using the passed value as the previous
value"
```
function (x ??= 123) {} // If passed null or undefined, x = 123
function (x &&= 123) {} // If passed a truthy value, x = 123
function (x += 123) {} // Regardless of type, add 123 to x
```
That said, I can see how allowing the arithmetic-assignment (and
concat-assignment) operators could lead hard-to-debug code that uses some
"I am very smart" shortcuts, so I'd opt to start with the
logical-assignment operators
On Tue, Oct 13, 2020 at 9:08 AM Naveen Chawla wrote:
> What about allowing any expression then?
>
> x || 4
> x/4
> x + 4
> x + w //maybe allow only "previous" parameter values as scope
> x + a //SyntaxError: 'a' undefined in parameters scope
>
> On Tue, 13 Oct 2020 at 14:39, Michael Luder-Rosefield <
> rosyatran...@gmail.com> wrote:
>
>> I know I am not the only one who has had several perfectly good use-cases
>> for default values disallowed, because the value coming in was `null`, not
>> `undefined`.
>>
>> I cannot be the only one who has let bugs slip in because of failing to
>> consider this case.
>>
>> So, if we can find a non-confusing and simple way to alter the spec to
>> allow for handling this, I imagine it would be considered useful and wanted.
>>
>> The obvious candidate is the nullish coalescing operator, which is
>> already part of the spec. Unfortunately, it is currently invalid to
>> indicate default values with it. I can't see any reason against changing
>> this.
>>
>> ```
>> function foo1 (x = 4) {
>> console.log(x);
>> }
>>
>> // currently causes SyntaxError
>> function foo2 (x ?? 4) {
>> console.log(x);
>> }
>>
>> foo1(null); // null
>> foo1(undefined) // 4
>>
>> foo2(null); // 4
>> foo2(undefined) // 4
>>
>> // currently causes SyntaxError
>> // should give x === null, y === 4
>> const { x = 2, y ?? 4 } = { x: null, y: null };
>> ```
>> --
>> Dammit babies, you've got to be kind.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Default values for nulls
What about allowing any expression then?
x || 4
x/4
x + 4
x + w //maybe allow only "previous" parameter values as scope
x + a //SyntaxError: 'a' undefined in parameters scope
On Tue, 13 Oct 2020 at 14:39, Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:
> I know I am not the only one who has had several perfectly good use-cases
> for default values disallowed, because the value coming in was `null`, not
> `undefined`.
>
> I cannot be the only one who has let bugs slip in because of failing to
> consider this case.
>
> So, if we can find a non-confusing and simple way to alter the spec to
> allow for handling this, I imagine it would be considered useful and wanted.
>
> The obvious candidate is the nullish coalescing operator, which is already
> part of the spec. Unfortunately, it is currently invalid to indicate
> default values with it. I can't see any reason against changing this.
>
> ```
> function foo1 (x = 4) {
> console.log(x);
> }
>
> // currently causes SyntaxError
> function foo2 (x ?? 4) {
> console.log(x);
> }
>
> foo1(null); // null
> foo1(undefined) // 4
>
> foo2(null); // 4
> foo2(undefined) // 4
>
> // currently causes SyntaxError
> // should give x === null, y === 4
> const { x = 2, y ?? 4 } = { x: null, y: null };
> ```
> --
> Dammit babies, you've got to be kind.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Default values for nulls
I know I am not the only one who has had several perfectly good use-cases
for default values disallowed, because the value coming in was `null`, not
`undefined`.
I cannot be the only one who has let bugs slip in because of failing to
consider this case.
So, if we can find a non-confusing and simple way to alter the spec to
allow for handling this, I imagine it would be considered useful and wanted.
The obvious candidate is the nullish coalescing operator, which is already
part of the spec. Unfortunately, it is currently invalid to indicate
default values with it. I can't see any reason against changing this.
```
function foo1 (x = 4) {
console.log(x);
}
// currently causes SyntaxError
function foo2 (x ?? 4) {
console.log(x);
}
foo1(null); // null
foo1(undefined) // 4
foo2(null); // 4
foo2(undefined) // 4
// currently causes SyntaxError
// should give x === null, y === 4
const { x = 2, y ?? 4 } = { x: null, y: null };
```
--
Dammit babies, you've got to be kind.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
