fix: only make $state variables reactive when read

[Ocean-OS]

Currently, if a variable is wrapped in $state, it will only actually be wrapped in $.state if it is reassigned. However, this doesn't account for whether or not the variable is read. This PR fixes this, so that only $state variables that are written to and read from are perceived as reactive. Here's an example:

let count = $state(0);
function reset() {
    count = 0;
}

This code declares a reactive variable and assigns to it, but never reads it, meaning that it wouldn't have to be reactive. Meanwhile this...

let count = $state(0);
function increment() {
    count++;
}

Is reactive, since to increment count, its previous value has to be accessed.

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: 766e6f0

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

[svelte-docs-bot]

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

[github-actions]

Playground

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

[Rich-Harris]

Are there any realistic scenarios were this optimisation would apply, but that editor tooling wouldn't report the variable as unused? I think it's preferable to avoid adding complexity to the compiler unless there's a tangible benefit

[Ocean-OS]

Are there any realistic scenarios were this optimisation would apply, but that editor tooling wouldn't report the variable as unused? I think it's preferable to avoid adding complexity to the compiler unless there's a tangible benefit

Well, one of the main reasons I made this was because I noticed in my bundles I would see lone $.states and $.deriveds because the bundler couldn't tell if the function was pure or not, and I think that it'd also add a little bit of a performance boost.

[Rich-Harris]

Can you share a repro? Am a little surprised to hear that, but I might be misunderstanding

[trueadm]

Well, one of the main reasons I made this was because I noticed in my bundles I would see lone $.states and $.deriveds because the bundler couldn't tell if the function was pure or not, and I think that it'd also add a little bit of a performance boost.

The fix sounds like we need to add /*#__NO_SIDE_EFFECTS__*/ around $.state and $.derived then?