feat: support for spreading function bindings

[jackgdll]

Closes: #16086

Adds support for spreading function bindings using ... syntax.

Before:

<script>
  const [get, set] = bindLowerCase(value);
</script>
<input bind:value={get, set} />

After:

<script>
  function bindLowerCase(value) {
    return [
      () => value.toLowerCase(),
      (v) => value = v.toLowerCase()
    ];
  }
</script>
<input bind:value={...bindLowerCase(value)} />

Works with arrays [get, set] and objects {get, set}.
If either get or set is nullish it's a noop.
If either get or set is not a function a runtime error is thrown.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 2825bce

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-16607-svelte.vercel.app/

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@16607

[Rich-Harris]

Thank you! I think this would need to run inside an effect, or use a derived, since otherwise something like this...

<input bind:value={...binding(validation, defaults)} />

...wouldn't update if validation or defaults did. Or to take an example similar to the one above, toggling uppercase has no effect, and it feels like it probably ought to.

[jackgdll]

Thanks! I wrapped the call to $.validate_spread_bindings in a derived and added a test for this case

[Rich-Harris]

Thanks — I actually missed before that both [get, set] and { get, set } are supported. To be honest I don't love this, it feels messy to me. I've never regretted having a stricter contract (and certainly not starting with a stricter contract), so personally I'd much rather it just be [get, set]. Having multiple ways to do something feels like it's just giving people options but in reality it creates confusion and makes the API as a whole less legible.

A nice bonus: no validate_spread_bindings required in prod, we can just use the array directly (albeit with optional chaining at the callsite). Thoughts?

[jackgdll]

Good point, having a stricter contract makes sense and makes the implementation and tests simpler, as well as being able to remove validate_spread_bindings in prod like you mentioned.
I've removed support for { get, set } and adjusted the tests and docs.

One quirk of the implementation that I noticed is that things like bind:value={...1}, bind:value={...true}, and bind:value={...{}} are all considered valid noops since 1[0] === undefined which seems like confusing behaviour.

Maybe validate_spread_bindings should throw if the expression isn't an array, or at least if it isn't iterable.
Or maybe this is something that the typescript compiler should be flagging. WDYT?