Hacker News Reader

Comment by sixstringtheory | Hacker News Reader

Doesn't that mean that all code written so far can't take up newer versions of the Go compiler for any other reason like new features/bugfixes/optimizations/etc without a full audit of codepaths involving for loops?

View on HN

No, the version declared in go.mod is different than the version of the toolchain used to compile the project. If you declare an older version even new toolchains will act like the previous versions.

No, it does not. Packages can compile using 1.22 and gain other benefits without opting into this change.

Ah, I didn't see the part about //go:build

Without /:go:build tags, you can just define 1.21 as your Go version in go.mod to opt out of new features while getting other benefits of the new compiler

No I don't think so; any old working code will be using the x := x workaround, which will keep working when going to this version with the changed loop mechanics. What may happen is a form of... some adage, I forgot the name, where code accidentally relies on the old behaviour and breaks when that old behaviour is no longer there.

(that same adage applies to e.g. browser manufacturers having to implement bugs to not break certain websites)

Are you thinking of Hyrum's Law?

Whatever, just give me an option to enable spacebar heating. https://xkcd.com/1172/

I enjoyed that reference :)

There isn’t really anything that you could actually use the old behavior for, any code that depends on it is probably wrong anyway.

Reply on news.ycombinator.com