Hacker News Reader

Comment by infogulch | Hacker News Reader

> To ensure backwards compatibility with existing code, the new semantics will only apply in packages contained in modules that declare go 1.22 or later in their go.mod files. ... It is also possible to use //go:build lines to control the decision on a per-file basis.

View on HN

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?

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

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

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 :)

Reply on news.ycombinator.com