fix: Remove unnecessary closure on bind with props

[adiguba]

I did a PR directly.
I don't know if it would have been better to do an issuer before...

But there just a very little thing that bothers me when we bind a prop :

<script>
	let { prop } = $props();
</script>

<input type="text" bind:value={prop} />

In the code above, the bind:value={prop} is compiled as the following line :

$.bind_value(input, prop, ($$value) => prop($$value));

But the closure ($$value) => prop($$value) is unnecessary, and can be directly replaced by prop :

-$.bind_value(input, prop, ($$value) => prop($$value));
+$.bind_value(input, prop, prop);

I added a unthunk() function that detect such call and return the callee.
It was used on BindDirective() to detech such code and fix it.
Maybe this could be used somewhere else...

Remarks :

• pnpm lint is OK
• pnpm test returns 2 errors, but this was already the case before this modification, and unrelated to this (packages/svelte/src/reactivity/date.test.ts and packages/svelte/src/reactivity/date.test.ts)

Svelte 5 rewrite

Please note that the Svelte codebase is currently being rewritten for Svelte 5. Changes should target Svelte 5, which lives on the default branch (main).

If your PR concerns Svelte 4 (including updates to svelte.dev.docs), please ensure the base branch is svelte-4 and not main.

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.

Tests and linting

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

[changeset-bot]

⚠️ No Changeset found

Latest commit: a86c7f7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[dummdidumm]

Thank you! This is potentially a tiny bit dangerous, for example in this case it would yield different results:

function foo(a, b = true) { console.log(b); }

function bar(callback) {
  callback(1, false);
}

bar((a) => foo(a)); // logs true
bar(foo); // logs false

That said, this isn't the case with any bindings, so it's safe to do here. Question is if it's still safe in the future. I slightly lean towards merging this, but would like some more opinions.

[paoloricciuti]

Thank you! This is potentially a tiny bit dangerous, for example in this case it would yield different results:

function foo(a, b = true) { console.log(b); }

function bar(callback) {
  callback(1, false);
}

bar((a) => foo(a)); // logs true
bar(foo); // logs false

That said, this isn't the case with any bindings, so it's safe to do here. Question is if it's still safe in the future. I slightly lean towards merging this, but would like some more opinions.

Ugh i was looking at this PR wondering if removing the thunk could've lead to problems because it sounded like it could. Personally i don't think having one less function call in generated code will impact anything so i lean towards the opposite...for the moment there's no situation like this but what if in the future the codebase evolves and we introduce something that does? If it was code that someone had to actually read or if it was an incredible performance improvement i would be ok in merging it but i think like this tradeoff.

[Rich-Harris]

This has been on my nice-to-have list for a while, so I'm glad to see it. I'm not too worried about the safety, since this isn't a transformation that applies generally, only when you use unthunk.

We could actually go even further and omit the latter prop — I opened #13269 as an alternative PR that builds on top of this one.

[Rich-Harris]

merged #13269 so I'll close this — thank you!