It renders correctly with bar = 1

However, if bar is marked as reassigned or mutated due to code somewhere else, it will have a runtime error:

<script>
	let bar = 0;
</script>

<h1>{bar = 1}</h1>
<h2>{bar}</h2>
<button on:click={() => {bar  }}>bar   </button>

The runtime error mentioned above is no longer happening as of 3.13.0, but there's another issue - the inline update in the template is only affecting the component's ctx object/array, and not the bar variable that's accessed in the event handlers. Changes made in the event handler are making their way into ctx (by way of $$invalidate) but changes to ctx can't find their way back.

was revisiting this, and realise that @Rich-Harris wrote a comment on this

we can mark it as referenced/mutated to prevent eslint to change it, but still i dont see any reason of wanting to write:

{bar = 1}

and regarding the impact on compiled output, i tried, it seems that the only difference is that, it will try to be reactive in the update function:

   if (dirty & /*bar*/ 4 && t4_value !== (t4_value = (/*bar*/ ctx[2] = 1)   "")) set_data_dev(t4, t4_value);

yet, as you said, the changes made here may / may not make its way back to the ctx, (depending whether we optimistically destruct the ctx array it in the params or not based on the number of variables), still it does not trigger $$invalidate to run the update cycle.

Writing something like {bar = 1} has come up a number of times, with people wondering how to do 'inline' assignments to variables, often for one iteration of an each loop. For example:

<script>
	let y;
</script>

{#each [1, 2, 3, 4, 5] as x}
	{(y = x * x, '')}
	<div>
		{y}
	</div>
{/each}

This is something we probably want to discourage, but at this point, depending on how many people are using it, it might not be something I feel comfortable making stop working.

A few months ago, something else I had suggested in chat was to make assignments from the template not trigger reactivity. That would let something like {foo} {(foo = 1, '')} {foo} work in a (possibly) slightly more expected way, where I think the two values shown for foo would differ. This might be a really bad idea, though, I'm not sure.

I suppose on the whole, I'm a little worried about doing something like #4492 and calling it a bugfix, because it seems to start to make a decision about some of this stuff that would be a bit hard to walk back later. I feel like I want to have at least some answers for how all this stuff should work before proceeding, and I don't think I do currently.

Closing as this behaves correctly in Svelte 5