Rest Equals Operator

💡 Ideas
1

JavaScript has a lot of assignment operators, even more so than other languages so why not add another one to the list .=

I envision it working kind of like this:


/// Use case 1
let xs = [1, 2, 3]
const ys = ['a', 'b', 'c']
xs .= ys
// xs = [...xs, ...ys]

/// Use case 2

let ws = { p: 1, q: 2 }
const zs = { r: 9, s: 8 }
ws .= zs
// ws = {...ws, ...zs}

/// Intersection 1

xs .= ws
// xs = [...xs, ...ws]
// Uncaught TypeError: ws is not iterable

/// Intersection 2

ws .= xs
// ws = {...ws, ...xs}
// {p: 1, q: 2, 0: 1, 1: 2}

I didn't go with ...= because it looks weird and has too many characters.
Is it worth adding to the language? I mean it just provides a quality of life improvement nothing too groundbreaking. What do you think :thinking:?

2

Because . isn’t an existing operator?

3 Likes
3

Those two cases are mutually incompatible: the first one uses the iteration protocol, the second one uses enumeration of object properties. A random value may be both iterable and have properties, so there is no way to disambiguate reliably the two cases.

2 Likes
4

Why does that matter in this case? .= is a separate operator. Can you explain

5

A random value with both the traits I assume is going to be an object with @@iterator:

If so then:

let obj1 = {
    *[Symbol.iterator]() {
        yield 1
        yield 2
        yield 3
    }
}

let obj2 = {
    *[Symbol.iterator]() {
        yield 9
        yield 8
        yield 7
    }
}

Here if we use obj1 .= obj2;
it should work exactly the same as:
obj1 = {...obj1, ...obj2}

Do you think it makes much sense to have it rather be:
obj1 = [...obj1, ...obj2]
or
obj1 = Iterator {...obj1, ...obj2}

6

All assignment operators are in the form "X=", where X is an operator, and X= is the assignment operator form of it. For an assignment operator to exist, a non-assignment one likely should too.

7

It could be ...= which would comply with this norm but isn't concise enough to be used as an assignment operator in my opinion so I shortened it to just .=

8

... is syntax, not an operator. The distinction is important.

9

Why does it matter? Why does including a dot as part of an operator cause any issues to the language?

10

Shorthand assignment operators follow the rule that

x += y;   ⇔   x = x + y;
x -= y;   ⇔   x = x - y;
x *= y;   ⇔   x = x * y;
x /= y;   ⇔   x = x / y;
x ||= y;  ⇔   x = x || y;
x &&= y;  ⇔   x = x && y;
x ??= y;  ⇔   x = x ?? y;

but

x .= y;   ⇔    x = x . y;

?

2 Likes
11

Is that a rule or a norm? I just think that it's a handy little syntactic sugar
Well if there exists such a rule that specifically focus on the syntax alone then:
x != y; ⇔ x = x ! y; isn't much different from x .= y; ⇔ x = x . y;

There exists a four character operator >>>= so ...= could be another pick instead.

12

It's both.

Rest and spread syntax (and semantics), though, isn't an operator, and doesn't have a LHS and/or RHS, so it wouldn't make sense as an assignment operator.

13

Not sure I understand the distinction between a rule and a norm. != or == are not shorthand assignment operators though, they are no covered by this convention.

The point is that x ...= y doesn't make sense, as x = x ... y is not valid syntax. There is no such ... operator, so there wouldn't be a ...= shorthand assignment operator either.

14

Why does it have be that there needs an infix operator X for there to be an X= operator? I'm asking how is that a rule? Is it in the Spec? Who established such a rule? A norm is kind of like an unspoken / unwritten rule. I think this argument falls under one such case.

15

Because that’s what the entire history of the language primes everyone to expect. Violating that would be surprising and confusing, although of course we could do it - so, we almost certainly wont.

1 Like