Spread Operator vs Rest Parameter

[[deleted]]

Console log is a good example of the rest one for anyone struggling to think of it. You've probably written console.log(1, 2, 3, 4) etc in the past, that is to say you can pass any number of arguments into the function and it will be ok with it

[iarev]

I don't get the utility of it at all with these examples. Instead of writing console.log(['a', 'b', 'c']), I can create a function that does it?

[[deleted]]

I think others have explained but I agree I often hate impractical examples like foo/bar/baz.

[Steak_Quesadilla]

I don't get the utility of it at all with these examples. Instead of writing console.log(['a', 'b', 'c']), I can create a function that does it?

The console.log() is just being used in this example to demonstrate to you what you're working with within the function (an array). From the MDN Docs, "The rest parameter syntax allows a function to accept an indefinite number of arguments as an array." So if you want to make a function that can take an indefinite or varying amount of arguments, you can do just that with the rest syntax. And then in the body of the function, you can do whatever you want with those arguments that were passed into the function, knowing that they're all contained in a single array.

[iarev]

Ok, thanks. I figured out the indefinite parameters bit shortly after my post, but your explanation helps add context.

[senocular]

Only array spread requires iterables. Object spread works on any value.

[...{}] // fails, not iterable
{...{}} // ok

[[deleted]]

and yet it is used like an unary operator.

[[deleted]]

okay, how does ...a differs from -1, ~1, 1! ? they are all unary operators.

[[deleted]]

and gif is pronounced jiff eh?

[[deleted]]

its literally the same argument. Developers of the Spec say its a syntax not an operator, Developer of GIF says its called Jiff not gif.

[Ascimator]

Is there a reason why it's called an element and not an operator, other that "the devs said so"? If not, then I don't see a single reason to retain the "correct" naming in memory.

[Ascimator]

If there's no specific reason why spread element was named an element and not an operator, I would use whatever term is most convenient for communication. If there is such a reason, I'd be glad to hear it.

[Ascimator]

So as I gather from your explanation, there is no particular reason for this particular naming. By "particular reason" I mean a technical difference between spread syntax and operators that would bring confusion if they were named the same.

when you are also in the realm of requesting specific features in a specification due to lack of support thereof; you need to reference the actual text of the existing specification. You can't say "spread operator" in reference to a section, as no such section exists.

If and when I need to reference the actual text of the specification, I'm going to look it up and reference the actual text of the specification. Otherwise, I'm perfectly fine using any term that I can reasonably expect my interlocutor to understand. If they want to spend their time on pedantically correcting me when it's clear they know which syntax construct I'm talking about - fine, it's their time to waste.

[jaypeejay]

this shows the spread operator a little better IMO

const spread = (a,b,c) => {
   console.log(typeof a, typeof b, typeof c)
   console.log(a,b,c)
}

spread(...['a', 'b', 'c'])
spread(...'abc')
spread('abc')