Svelte incorrectly interprets values using Symbol.toPrimitive as static

[Ocean-OS]

Describe the bug

If a value in Svelte uses Symbol.toPrimitive for reactivity, Svelte doesn't see this in compilation and interprets the value as static. Here's an example:

<script>
let count = $state(0);
let counter = () => count;
counter[Symbol.toPrimitive] = () => count;
</script>
<button onclick={()=>count++}>Count is {counter}</button>

In this example, counter uses Symbol.toPrimitive in an (admittedly dumb) attempt to add some reactivity without requiring a (visible) function call.
However, the code that interpolates counter compiles to:

button.textContent = `Count is ${counter ?? ""}`;

...which is a static statement with no reactivity.
While I have found that wrapping the value in $state like so...

/*... insert stuff from example... */
let reactiveCounter = $state(counter);
/* replace `Count is {counter}` with `Count is {reactiveCounter}`... */

...makes everything work, this feels like more work than necessary, since count is still a "dependency" of counter (and in turn reactiveCounter).
This is an edge case, but it would be useful if these values could be correctly interpreted as reactive by the compiler.

Reproduction

REPL

Logs

No response

System Info

N/A

Severity

annoyance

[Leonidaz]

Svelte only compiles a variable to be included in template effects if the variable is a state / signal declared at the top level, object property or a function. Otherwise, if it seems like a primitive it will not be reactive.

e.g. compiled code for a function: $.template_effect(() => $.set_text(text, `Count is ${counter() ?? ""}`));

Since JavaScript is not a strongly typed language, it's really not possible to do a static code analysis to determine what actually functions return.

SIDE NOTE: I've been mulling over an idea to introduce a rune for a signal hint for svelte. I know that the recommendation is to use object / class instances vs primitives but I think it will be still quite useful and eliminate a lot of questions / issues on why something is not reactive. And, would be really nice for composition and library authors.

[7nik]

This is intentional. Duplicate of #14803, #13525, #13054, #9860 + related #11012 and #10629

[trueadm]

As mentioned above, this is by design. The compiler cannot statically determine something has toPrimitive or valueOf etc, so instead, we bail-out. Otherwise we'd have have to assume everything might be reactive.