This has come up multiple times. You are mutating state inside the template expression, which is kind of undefined behavior. Something that in my opinion should straight up not compile in Svelte 4. You are relying on the order in which Svelte decides to do things, which is not necessarily from top to bottom because this is not a templating language but a living application. Svelte can do things in whatever order it thinks is most efficient. Someone with knowledge about internals can probably tell you exactly why you are seeing what you are seeing, which could actually be different between Svelte versions. In fact check out 3.0.0 https://svelte.dev/repl/2b54f8e14ae7455d8f653cc954d32c50?version=3.0.0

Related

#3793
#5897
#5893
#5460
#7229

Yup, changing component state inline in the template is undefined behavior. Preventing this at compile time would be nice to do in Svelte 4 where possible, but we're not going to be able to catch cases like this where there's no visible assignment and instead the state change happens in a method that mutates state.

@Conduitry @Prinzhorn if we want to avoid arbitrarily supporting inline logic like this, what if Svelte added support for helper statements/blocks similar to {@const} like {@set} where the state for one or more stately variably could be redefined within template logic:

<script>
  let arr = [1, 2, 3];
  let index = 0;
</script>

{#each arr as elem, i}
  {@set index  } <!-- or {@set index  = 1} or {@set index = index 1} -->
  This {index === i ? 'works' : 'doesn\'t work'} when `i` equals {i}, where `index` equals {index}.
{/each}

Giving it its own syntax doesn't resolve any of the concerns with how it should behave. {@set} would need to contend with everything that {} does now.

That's still undefined behavior. When would @set execute? Svelte is a living document, this is not an old fashioned templating language that is executed top down. Your #each is alive. Changing arr might only update a subset of the items. Adding items to arr in your example would just keep growing index. I don't understand the use-case for something like this at all. It doesn't make sense to me outside of a "classic" templating language (it might make sense for a single SSR pass without hydration, but that's exotic).

If you think you have a use-case that Svelte does not support in a nice way and that doesn't already have an open or clsoed feature request, then please provide such a feature request. But in a more detailed way than your comment (the feature request issue template will guide you).

@Prinzhorn Of course. Just contributing to the discussion here. I see your point about the template being alive and the declarative vs. imperative conflicts something like {@set} could cause.