Is it spread "syntax" or the spread "operator"?

Other uses of the syntax

There are other numerous uses of spread/rest syntax not covered in the main answer. They include:

• Rest syntax in function parameters
• Array and object¹ destructuring assignment
• Object spread syntax in object literals¹

Rest syntax

A use for spread syntax, commonly referred to as rest syntax, is used for a variable number of arguments in a function's arguments. This differs from spread arguments, used to pass arguments to a function call based on an iterable's elements. For example:

function add(...addends) {
  …
}

Here, rest syntax is used for the function add to receive the rest of the arguments in the identifier addends. This does seem to evaluate to a singular value as addends is an array of the passed arguments, but what if we tried:

function foo(...[bar, baz]) {
  …
}

Here, bar and baz would both be assigned a value corresponding to the first and second arguments passed -- thus this doesn't always evaluate to one value. The underlying problem is that ...addends in the first example and ...[bar, baz] in the second doesn't actually evaluate to a value at all - it's just used during the operation of assigning an array of the arguments to the identifier. Thus, it's syntax to allow a variable number of arguments to a function, not an operator.

Destructuring Assignment

Spread syntax can also be used during array destructuring assignment and is actually referred to as a rest element in the language specification (because when using in destructuring, it gets the rest of the destructured iterable). A convincing argument can be made as this does seem like an operator:

const [...bar] = [1, 2, 3];

It's used like a prefix unary operator. Here, bar evaluates to [1, 2, 3] — which is a single value. But this doesn't always happen, for example:

const [first, ...[second, third]] = [1, 2, 3];

Here, first, second, and third evaluate to 1, 2, and 3 respectively. But ...[second, third] assigns to two identifiers, not one, and doesn't evaluate to a singular value, but two. Just like rest syntax, the underlying problem is that ...bar in the first example and ...[second, third] in the second doesn't actually evaluate to a value at all -- it's just used during the operation of assignment. Thus, it isn't an operator at all², just new sytax to aid in unpacking values.

Object spread syntax

A final use for spread syntax is in object literals, commonly referred to as 'object spread properties' in which a target object's own enumerable properties are spread to another, for example:

const foo = { ...bar };

This isn't an operator, just like array spread syntax isn't an operator. The concept is the same, instead of indices and elements in arrays, bar's enumerable keys and values are spread to foo. Here, a collection of bar's properties is spread -- not just one single value, thus it does not fit the definition of an operator.

---

¹Object rest/spread properties are currently in the Stage 3 proposal for ECMAScript, and will very likely be added in the near future

² Another problem with destructuring assignment being an operator, aside from semantics, is that the language specification defines it as supplemental syntax --  not a supplemental operator, and rightfully so. It’s not standalone, as this won’t work:

const ...bar = [1, 2, 3, 4];

It’s contextual, only allowed in, by the language’s grammar, object literals and array literals that are left-hand-side expressions. It’s also grammar that refines the interpretation of a left-hand-side expression. Again, this is an extension to add new syntax to the language, a refinement to existing grammar. That reaffirms the argument with specification.

It's not an operator.

In all senses of the word, it's not one. It has been a huge misconception since it was introduced and despite popular opinion -- it's not one, and there are a few objective points to be made:

• It doesn't fit the definition of an operator
• It can't be used as an operator
• The language specification implies that it's not an operator

It should be mentioned that spread syntax comes in different 'flavors', used in different contexts and are commonly referred to by different names while using the same punctuator. Spread syntax is basically an umbrella term for the application of the ... punctuator, and see Felix Kling's great answer detailing all the uses and names. More explanation about these individuals uses is given in the supplementary answer.

What is an operator?

Semantically, in the context of ECMAScript, operators are just builtin functions that take in arguments and evaluate to a single value -- written in prefix, infix, or postfix notation and usually with symbolic names such as + or /. From Wikipedia:

Simply, an expression involving an operator is evaluated in some way, and the resulting value may be just a value (an r-value), or may be an object allowing assignment (an l-value).

For example, the + operator results in a value such as 2, which is a right-hand-side expression, and the . operator results in an object allowing assignment such as foo.bar, a left-hand-side expression.

On the surface, the ... punctuator¹ looks to be a prefix unary operator:

const baz = [foo, ...bar];

But the problem with that argument is that ...bar doesn't evaluate to a singular value; it spreads the iterable bar's elements, one by one. The same goes for spread arguments:

foo(...bar);

Here, foo receives separate arguments from the iterable bar. They're separate values being passed to foo, not just one value. It doesn't fit the definition of an operator, so it isn't one.

Why isn't it an operator?

Another point to be made is that operators are meant to be standalone and return a single value. For example:

const bar = [...foo];

As already mentioned, this works well. The problem arises when you try to do this:

const bar = ...foo;

If spread syntax were an operator, the latter would work fine because operators evaluate the expression to a single value but spread doesn't so it fails. Spread syntax and spread arguments only work in the context of arrays and function calls because those structures receive multiple values supplied by spreading array elements or arguments. Evaluating to multiple values is outside of the scope of what an operator is able to do.

What do the standards say?

The complete list of operators is listed in Clauses §12.5 through §12.15 in the ECMAScript 2015 Language Specification, the specification in which ... is introduced, which doesn't mention .... It can also be inferred that it's not an operator. The two main cases mentioned in this answer in which spread syntax is in a production, for function calls (spread arguments) or array literals (spread syntax) are described below:

ArrayLiteral :
  [ Elisionopt ]
  [ ElementList ]
  [ ElementList , Elisionopt ]

ElementList :
  Elisionopt AssignmentExpression
  Elisionopt SpreadElement
  ElementList , Elisionopt AssignmentExpression
  ElementList , Elisionopt SpreadElement

Elision :
  ,
  Elision ,

SpreadElement :
  ... AssignmentExpression
  

And for function calls:

CallExpression :
  MemberExpression Arguments

Arguments :
  ( )
  ( ArgumentList )

ArgumentList :
  AssignmentExpression
  ... AssignmentExpression
  ArgumentList , AssignmentExpression
  ArgumentList , ... AssignmentExpression
  

In these productions, there's a conclusion that can be made: that the spread 'operator' doesn't exist. As mentioned earlier, operators should be standalone, as in const bar = ...foo and evaluate to one single value. The syntax of the language prevents this, which means spread syntax was never meant to be standalone. It's an extension to array initializers and function calls, an extension to their grammar.

Why spread 'syntax'?

Syntax, as defined by Wikipedia:

In computer science, the syntax of a computer language is the set of rules that defines the combinations of symbols that are considered to be a correctly structured document or fragment in that language.

Syntax is basically the 'form' of the language, rules that govern what is legal or not regarding how the code should look, and how the code should be written. In this case, ECMAScript's grammar specifically defines the ... punctuator to only appear in function calls and array literals as an extension -- which is a rule that defines a combination of symbols (...foo) that are considered to be legal together, thus it is syntax similar to how an arrow function (=>) is not an operator, but syntax².

Calling ... an operator is a misnomer. An operator is a builtin function that takes in arguments (operands) and is in the form of prefix, infix, or postfix notation and evaluates to exactly one value. ..., while satisfying the first two conditions, does not satisfy the last. ..., instead, is syntax because it is defined specifically and explicitly in the language's grammar. Thus, 'the spread operator' is objectively more correctly referred to as 'spread syntax'.

---

¹ The term 'punctuator' refers to punctuators in ECMAScript 2015 and later specifications. These symbols include syntax components and operators, and are punctators of the language. ... is a punctuator itself, but the term 'spread syntax' refers to the whole application of the punctuator.

²=> itself is a punctuator, just as ... but what I'm referring to specifically is arrow function syntax, the application of the => punctuator ((…) => { … }), just as spread syntax refers to the application of the ... punctuator.