Related: rest end only but not rest start only?
I also recall this being discussed on the old es-discuss mailing list, but dredging through that isn't something I feel like doing.
I'd like to see stuff like (a, ...bs, c) => ...
be possible. To name a few examples of use case and precedent:
- Node's callback idiom the whole time has been
f(...args, callback)
, and any function forwarding all but the callback needs to have such a prototype.
- GitHub - scijs/ndarray: 📈 Multidimensional arrays for JavaScript has an
ndarray.set(...indices, value)
.
- CoffeeScript supported this since before ES6. ES6 got its very rest parameter idea in part from it, so it's pretty strong precedent. I think Babel and/or Traceur also once supported it as an extension way back then.
There's of course a lot more, and I could probably spend hours just finding and adding precedent here.
1 Like
I also found this, and I'm not sure why it didn't show up in my search results: Inverse Rest Operator
This is a near dupe of that, just a little more detailed.
I think this would be great. If I recall correctly from when rest parameters were added, the restriction was not due to any objections or challenges, it was just to make a small first step.
Note that we'll have to make sure there's an easy way for the average developer to understand the interactions between non-final rest parameters and default parameters. Banning their mixing is probably the easiest way to go about it.
If I recall correctly from when rest parameters were added, the restriction was not due to any objections or challenges, it was just to make a small first step.
Yeah, avoiding [...foo, bar]
let us skip answering some hard questions and just get the 90% use-case solved. No matter what you define, people can expect different behavior for let [a, ...b, c] = [1]
/etc, so it's a much tougher judgement call.
I think we can learn a lot from the choices and experience of CoffeeScript there. IMO this proposal is very much in the realm of feasible.