I see your point. I think we're just using a different definition of "no-op".
The statement by itself doesn't produce any visible side effect.
However it creates a new logical variable in the abstract machine, and that can have real consequence in the real underlying machine, depending on which statements happen next.
In particular, the new variable and the old variable are independent and thus the new variable may require to allocate some storage location (e.g. on the stack, a register, ...) to keep track of further mutations to its value (I say "may" because an optimising compiler may do without that extra location)
the two lines doing different things even though looking exactly the same.
I'm a Scala dev and in Scala we have a similar thing, where a new import or definition in the middle of the code can change line semantics between two equal lines.
But the difference is that this is not a mistake but a concious design to switch "contexts" and is heavily guarded by the typesystem, where GOs typesystem is incredibly weak in comparison, which is not an inherent drawback, but here it is.
I do feel that I'll stick to my feelings that this design is confusing and should have been avoided from the beginning. Ku
udos to the go team for breaking compatibility here. This is necessary for a language to not become another COBOL.
You can't declare the same variable twice in the same scope.
item := item
works only because it declares a new variable in the current scope, initialized with a variable with the same name (but different variable) from the outer scope.
Go distinguishes declarations from assignments. In this example, the second assignment is a no-op indeed.
What does the print function exactly do if I pass a variable to it.