| > 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. |
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.