chore: delete weird code

[Rich-Harris]

no idea what this highly suspicious code is supposed to be doing, but no tests fail if we delete it. closes #9556

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]

🦋 Changeset detected

Latest commit: 01428b3

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

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
svelte-5-preview	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 27, 2023 5:50pm

[dummdidumm]

I don't think we can remove this code. It guards against static things becoming accidentally reactive because they happen to be on the same text node as an actually reactive variable. We should add a test for this.

[Rich-Harris]

Huh. I didn't realise we were doing that.

It seems pretty weird to be honest. Why would we use the initial value in render effects (assuming we were in fact doing that, and not the current thing where we only do that if it's a standalone {identifier}), but the current value in user effects? (And it's not like we could use the initial value in user effects in the general case, if we wanted to remedy the inconsistency in that direction.)

This is the current behaviour on main and it doesn't make a whole lot of sense to me.

In my view it would be much better to print a 'hey you probably didn't mean this' warning if

• a non-state value is updated in a closure, and
• that value is referenced in the template (other than in an event handler etc)

but otherwise just let it update at random times. I don't think the current behaviour matches any plausible user intent.

[dummdidumm]

I vaguely remember that this was built in when we were more broad with how changes result in view changes, i.e. one render effect for everything. That made people raise pitchforks, questioning how this is fine-grained reactivity when it now updates more broadly in certain situations than Svelte 4.
I'm not saying it must stay this way, but this was the reasoning back then.