Cannot use runes with class fields using a Symbol identifier

[dangodai]

Describe the bug

Disclaimer: I'm unsure if this is a bug or just unsupported, but the docs don't seem to mention it at all and the error message is not precise to the problem.

Class fields using a Symbol as their identifier/key cannot be assigned runes (state, derived, etc). See the reproduction below.

I suspect that the compiler should be transforming the Symbol field into a get/set pair backed by a private field as the docs claim to do for class fields. Doing this manually is a workaround in the meantime.

If that isn't possible then clarification in the docs and the error message would be appreciated.

Reproduction

Reproduction and example workaround: https://svelte.dev/playground/dd94e0351ecf4d28b26eb81098171351?version=5.41.2

In short, the follow code

class Foo {
	[Symbol()] = $state();
}

Results in the error

`$state(...)` can only be used as a variable declaration initializer, a class field declaration, or the first assignment to a class field at the top level of the constructor.
https://svelte.dev/e/state_invalid_placement

Logs

System Info

System:
    OS: Linux 6.15 Arch Linux
    CPU: (12) x64 AMD Ryzen 5 2600 Six-Core Processor
    Memory: 6.37 GB / 15.54 GB
    Container: Yes
    Shell: 5.3.3 - /bin/bash
  Binaries:
    Node: 22.17.0 - /home/yung/.nvm/versions/node/v22.17.0/bin/node
    Yarn: 1.22.22 - /usr/bin/yarn
    npm: 10.9.2 - /home/yung/.nvm/versions/node/v22.17.0/bin/npm
    pnpm: 10.13.1 - /home/yung/.local/share/pnpm/pnpm
  Browsers:
    Chromium: 139.0.7258.66
    Firefox: 141.0
    Firefox Developer Edition: 141.0
  npmPackages:
    svelte: ^5.39.9 => 5.39.9

Severity

annoyance

[Ocean-OS]

This isn't a symbol-specific thing, it's just because you can't make computed $state class fields. Although, in theory, this might be feasible; I'll get a draft PR ready tonight.

[dangodai]

This isn't a symbol-specific thing, it's just because you can't make computed $state class fields. Although, in theory, this might be feasible; I'll get a draft PR ready tonight.

Yeah, I had a quick skim of the compiler after posting and noticed that. Do you know the reason for this?

The only problem I can this of is that creating a Symbol inline with the property definition can't naively be expanded to a get/set pair. That is

class Foo {
	[Symbol()] = $state();
}

Is not equivalent to

class Foo {
	// What do you even name this?
	#_symbolName = $.state(1);

	get [Symbol()]() {
		return $.get(this.#_symbolName);
	}

	set [Symbol()](value) {
		$.set(this.#_symbolName, value, true);
	}
}

Because you end up with 2 different symbols for your get/seters. This case should probably be prohibited still.

But otherwise it seems like computed properties should be fine? At the very least, one whose entire expression is an identifier should be fine, but even something like [1 + 2] = $state() should work, no? Users could of course make computed values that are dynamic but that's more of a user error than something for Svelte to worry about.

[Ocean-OS]

Well, the current reason computed properties can't be used is since their keys might not be idempotent, meaning they return the same result each time they're evaluated. For example:

let i = 0;
class Foo {
  [i++] = $state(0); 
} 

when expanded into a getter/setter pair, i is incremented twice, and the keys end up being different. So, the solution I'm thinking of is something like this:

let i = 0;
let key; 
class Foo {
  #_1 = $.state(0);
  get [key = i++]() {
    return $.get(this.#_1); 
  }
  set [key](v) {
    return $.set(this.#_1, v); 
  }
}