Hacker News Reader

Comment by tapirl | Hacker News Reader

Don't forget that the semantic change of traditional 3-clause "for" loops: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...

Because of this change, Go 1.22 is actually the first Go version which seriously breaks Go 1 compatibility, even if the Go official doesn't admit the fact.

View on HN

> since Go 1.22, every freshly-declared loop variable used in a for loop will be instantiated as a distinctive instance at the start of each iteration. In other words, it is per-iteration scoped now. So the values of the i and v loop variables used in the two new created goroutines are 1 2 and 3 4, respectively. (1+2) + (3+4) gives 10.

I think you are assuming more guarantees than are actually guaranteed.

You have a well-documented history of making incorrect claims about Go compiler and runtime behaviors, so this isn't surprising.

> since Go 1.22, you should try to specify a Go language version for every Go source file

What on Earth?? Absolutely 100% not.

It looks you don't understand the change at all.

The statement "since Go 1.22, you should try to specify a Go language version for every Go source file" is made officially, not by me.

> You have a well-documented history of making incorrect claims about Go compiler and runtime behaviors, so this isn't surprising.

The claim is totally baseless.

All my opinions and articles are based on facts. If you have found ones which are incorrect or which are not based on facts, please let me know: https://x.com/zigo_101.

> The statement "since Go 1.22, you should try to specify a Go language version for every Go source file" is made officially, not by me.

Please provide a link to documentation on golang.org. Note: not a comment in a GitHub issue, not a blog article -- official stuff only.

> baseless

It should be evident by the consistent responses to your GitHub issues that nobody takes you seriously. Which is unsurprising, when you make recommendations like

> Anyway, since Go 1.22, you should try to specify a Go language version for every Go source file, in any of the above introduced ways, to avoid compiler version dependent behaviors. This is the minimum standard to be a professional Go programmer in the Go 1.22+ era.

I think it is best to let rsc answer your questions. :D

:D :D I don't have any questions :D except to you :D

Are there cases where people actually rely on the previous behavior?

I always assumed that it was considered faulty to do so.

There were certainly buggy tests that relied on the old behavior. We didn't find any actual code that relied _correctly_ on the old behavior.

https://go.dev/wiki/LoopvarExperiment

Love it, even though it must have been incredibly confusing when old tests failed at first. The assumption being that the tests were correct. They _passed_ all those months or years!

I'm just also watching your YT video on testing and enjoying it very much!

The tests are in the simplest forms, there are more complex use cases of traditional "for" loops. The complex cases are never explored by the authors of the change.

And there are a large quantity of private Go code in the world.

No convincing evidences to prove there are not such cases. In my honest opinion, if there are such cases in theory, there will be ones in practice. It is a bad expectation to hope such cases never happen in practice.

The authors of the change did try to prove such cases don't happen in practice, but their proving process is totally breaking.

It is my prediction that multiple instances of broken cases will be uncovered in coming years, in addition to the new foot-gun issues created by the altered semantics of transitional 'for' loops.

Reply on news.ycombinator.com