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

Playground

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

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.

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

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?

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?