Discuss
  • [Proposal] Optional spreading

[Proposal] Optional spreading

# Scott Rudiger (5 years ago)

I like it; code seems cleaner to me with its use. However, since the syntax is so similar to optional chaining, it's too bad your goal with this sample is to check for falsey values rather than nullish values.

[ 1, ?...(condition && [2, 3]), /* no extras:) */ 3, ]
# Jordan Harband (5 years ago)

Since you can do this now with:

[
  1,
  ...(condition ? [2, 3] : []),
  3,
]

and object spreading already handles this for you, is extra syntax really needed?

# Beknar Askarov (5 years ago)

Indeed. I see your point.

But it really needs to be falsy check. Since falsy values are not "spreadable"

# Beknar Askarov (5 years ago)

@Scott My mistake empty string [...""] is spreadable. But not sure if it is desirable behavior.

# Beknar Askarov (5 years ago)

And it does result in empty array

[...''] -> []

So not much difference even if it passes through. Everything else would result in error if check was only nullish

# Cyril Auburtin (5 years ago)

Like others said, this idea is good, but I think we can already achieve something decent and succinct enough

arrays:

// group by name, and accumulate data:
arr.reduce((m, {name, data, ...o}) => m.set(name, {...o, data:
[...m.get(name)?..data||[], ...data]}), new Map())

objects: {foo: 1, ...cond && {bar: 2}, qux: 3} gist.github.com/caub/7494b4391c2d62c49b565d2cfc2c0c1f#file

# Beknar Askarov (5 years ago)

@Scott Rudiger After thinking more about it. I would not like to conflict with semantics of optional chaining and null coalescing operator. So in order to not confuse people, maybe introduce two types of optional spread operators

  1. ?... - Do not spread if nullish. Note nullish. Else try to spread. Signature Array: [?...(nullish | Iterable)]; Signature Object: {?...(nullish | object)};

  2. !... - Do not spread if false. Note FALSE not falsy. Else try to spread. Signature Array: [!...(false | Iterable)]; Signature Object: {!...(false | object)};

I think this can be an option to avoid consfusion

Why not !... to check for all falsy and do not spread of falsy? To avoid confusion and make developers to know their types

For example:

[!...(0 ?? [1 , 2])]; // throws TypeError. number 0 is not iterable

So better will be to use:

[!...(!!0 ?? [1 , 2])];
// OR
[?...(0 ?? [1 , 2])];

What do you think?

# Herby Vojčík (5 years ago)

On 23. 8. 2019 16:24, Beknar Askarov wrote:

@Scott Rudiger After thinking more about it. I would not like to conflict with semantics of optional chaining and null coalescing operator. So in order to not confuse people, maybe introduce two types of optional spread operators

  1. ?... - Do not spread if nullish. Note nullish. Else try to spread. Signature Array: [?...(nullish | Iterable)]; Signature Object: {?...(nullish | object)};

  2. !... - Do not spread if false. Note FALSE not falsy. Else try to spread.

I read

!...foo

as

!(...foo)

that is, logical not. I'd tip it already works that way. In which case no go, break compat.

Herby

Signature Array: [!...(false | Iterable)]; Signature Object: {!...(false | object)};

I think this can be an option to avoid consfusion

Or add a new one. :-(

# Beknar Askarov (5 years ago)

Thank you, everyone, for feedback. Sorry for not getting back for a while. I had some time to think and concluded that nullish noop in spreading is a good feature to be added to the language without complicating it too much. So please take a look at the explainer gist.github.com/askbeka/8bb17508ec250a789ea9bff683a50e38 and lets

discuss in es-discourse proposal es.discourse.group/t/optional-spreading-proposal/224, if you have

further feedback, please share

# Jordan Harband (5 years ago)

Since object spread already ignores nullish values, a syntax change would only be needed for array spread. Then, the two kinds of spread would support different syntactic features, which seems inconsistent.

# Bob Myers (5 years ago)

Wouldn't simply making array spreading ignore nullish values be backward compatible? Unless one imagines that people are depending on this being an error somehow.

# Jordan Harband (5 years ago)

No, it wouldn't - see tc39/ecma262#1069.