[naasking]

> Why are dead variables any dirtier than dead stores?

If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this.

If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

In principle, a dead variable in final code is also almost certainly a mistake: either by not including the variable in the computation or for declaring the variable at all. Maybe a little annoying while you're figuring something out, but makes sense in the context of polished code.

[masklinn]

> If you mean stores to fresh local variables

I mean stores for which there is no load.

> I assume that should also count in a proper/ideal implementation of this.

It certainly does in a proper implementation, but not in zig. Or go.

> If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

That sounds stupid.

> a dead variable in final code is also almost certainly a mistake

See “final code” is the issue at hand. The problem with go is that it specifically does not do that. It has a half-assed implementation which it forces upon you all the time.

> Maybe a little annoying while you're figuring something out

It’s a bloody nuisance when you new figuring things out or in the middle or refactoring something.

> but makes sense in the context of polished code.

There’s a ton more which makes sense “in the context of polished code” which go can’t be arsed to do.

Checking that errors are not implicitly ignored for starters.

[naasking]

> I mean stores for which there is no load.

Stores for which there are no load can still be observable in concurrent scenarios. That's why I specified stores to locals with no load because those are not observable.

> That sounds stupid.

Sounds totally reasonable to me in scenarios where you need the output of the compiler to be very predictable.