Rest/spread placeholder

[haltcase]

prior art

• the old babel-plugin-partial-application:

  const log = console.log('hi', ..._)

• TC39 proposal:

  const log = console.log('hi', ...)

These are both roughly equivalent to:

const log = (..._arg) => console.log('hi', ..._arg)

param.macro

input:

import { _ } from 'param.macro'
const log = console.log(..._)

current output:

const log = (_arg) => {
  return console.log(..._arg);
};

This ends up having to be called with an array (or other spreadable object) to work, ie. log([1, 2, 3]). Otherwise it throws an error.

proposed output:

const log = (..._arg) => {
  return console.log(..._arg);
};

This would be a breaking change at this point so it'd have to drop in v2.0.0 - but probably should happen.

[haltcase]

Closed by 8a47350.

[rajington]

Hey @citycide, great work on this library.

I'm curious with this pattern how to intentionally spread the first argument.

A good use case would be partially applying React components:

const Header = ({ title, subtitle}) => (
  <>
    <h1>{title}</h1>
    <h2></h2>
  <>
)

const CheckoutHeader = Header({ title: 'Checkout', ..._})

[haltcase]

@rajington hey 👋 , thanks

This would very likely require a new symbol specifically for this "asymmetric" rest/spread parameter. I've got a high bar for introducing additional symbols — I was reluctant to add lift but it's useful in several scenarios. This one would be more single-purpose.

One of my main goals is also to maintain a balance of sugar and clarity. And right now that balance is arguably as good it gets by doing these:

const CheckoutHeader = props => Header({ title: 'Checkout', ...props })
const CheckoutHeader = Header({ title: 'Checkout', subtitle: _ })

As always you're welcome to make a strong case in favor of it.

[rajington]

Thanks for the quick reply, I feel there's some ambiguity that I misinterpreted and I could see how ..._ is the better of the two.

Could ...(_) work as a way to intentionally spread just the first param? Parens are already used to change intention of their contents (e.g. () => {} vs () => ({})) and maybe adding syntax with an example of spreading the first param could make the distinction more clear while still supporting both.

[haltcase]

@rajington it would be possible — Babel adds an extra object to the AST node with a parenthesized property. I'm not opposed to using it but is it really obvious that parenthesizing the spread placeholder would alter it that way?

[rajington]

Yeah, hard to say ...(_) would be obvious without showing usages/implications of both, but potentially something that people could learn once and remember easily, and likely no one will be wrapping it needlessly and getting unexpected results.

Also maybe it's not that big of a deal to not have a way to spread the first prop, I'm worried others might combine them in the way that I had but can definitely wait for it to come up.

Maybe I should move this to the TC39 proposal? Not having the bare ... and adding the parens seems to account for all cases:

macro y =	transpiled y =	y(a,b) calls f with
f(_)	(x) => f(x)	a
f(..._)	(...x) => f(...x)	a, b
f([..._])	(...x) => f([...x])	[a, b]
f({..._})	(...x) => f({...x})	{0: a, 1: b}
f([...(_)])	(x) => f([...x])	[...a]
f({...(_)})	(x) => f({...x})	{...a}

[haltcase]

@rajington there was already some discussion on the proposal over here, which is in part why the ... rest/spread syntax has been removed from the initial proposal and saved for later.

Feel free to introduce them to the idea. I'd be much more open to implementing that if it were backed up by an upcoming proposal.

[rajington]

That makes a lot of sense, thank you so much for your help. This is such an exciting area!