To documentation that we consider "official" speaks in syntax does not speak of operator.
Then you may be thinking that you saw in the same written documentation that is operator according to the link exposed. But it is not the same. It’s a translation into Portuguese, and our culture is to do everything more or less, we don’t care about quality and we don’t care about the details that make something right or wrong. Someone took it to translate the documentation, was arrogant and thought he could translate to something better than the original, changing the meaning and generating confusion. So I always advise people to look at what is in English, almost 100% of the time is better. There are things about Brazil that are better in English. Specifically this translation is very bad, a real disservice.
The original version makes it clear that it is a syntax and that it does something different from an operator. This syntax can only be used in certain places and not anywhere where an operator can be, including what results is not a value but another syntax, so there is no way that this is an operator. The result is a syntax with a list of elements of the enumerable object used as an argument from spread. Does not return a array or another enumerable object, does not return a unique value, returns something to be filled syntactically where it fits, i.e., in a function call or a literal of array.
In fact the documentation is in the operators section, which is a mistake, but maybe they didn’t find where to enter. And the specification is very weak with regard to this and in an informal introduction it speaks in operator, nowhere else even hints that it is an operator.
The doubt is good and raises something curious. C++ as well as Ecmascript are created by committees and institutional participants are not so different from each other (people are), and rarely do you see anything flawed or ambiguous in the C++ specification, other than they are preparing to use "proving" code what’s in the specification. Javascript was born in a very good way turns and mambembe, and it seems that evolution is not taking so much care. When there’s a silly flaw like that It’ll be that they’re making decisions sparingly?
Anyway the specification shows that this syntax can only be used in object initializers, array and argument lists. An operator does not have all this restriction. His analysis is correct.
We can say in a way that it is a macro expansion encrusted in language. So what ...arr
does is expand for a code equivalent to 1, 2
(attention to the fact that it is not a value like this, it is a text for the code). Exactly the mechanism used for this I do not know and it was not clear in the specification whether there is a "right way" to do, so I believe that each implementation can do as you want and have a kind of eval()
applied there, or that all places that accept this syntax can be exchanged for something different compatible with what already exists, etc. So let var1 = ...arr;
would result in let var1 = 1, 2;
and this syntax is invalid, this does not exist in Ecmascript. That’s why inside []
or ()
works, after all [1, 2]
or (1, 2)
are valid syntax in certain contexts, although it may not be what you want to do.
I did my part of improve translation to reflect what was in the original. I do not want to take the reference to operators without changing the original in English and to do something so radical I would like to discuss it before and not run over, but still do not know how to do this.
What would you expect to happen in
let var = ...arr
if "the spread were an operator", as he quotes?– Woss
Return some value, since an operator is said. For example, return
[1, 2]
.– Thiago Krempser
But it does not at any time. Why would an operator return a list from a list? It would be the same as not using it.
– Woss
@Andersoncarloswoss If I trade for
let var1 = [...arr]
works.– Thiago Krempser
In fact the main point of doubt is whether or not the spread is an operator by definition.
– Thiago Krempser
@Andersoncarloswoss The example is just a test to show that it cannot be called "operator".
– Thiago Krempser
The specification defines the syntax
...value
as an Object Initializer, which is an expression. http://www.ecma-international.org/ecma-262/9.0/#sec-Object-initializer– vinibrsl