4 ms·
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
by sixstringtheory 3y ago
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?
- kevincox 3y agoNo, 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.
- ericpauley 3y agoNo, it does not. Packages can compile using 1.22 and gain other benefits without opting into this change.
- sixstringtheory 3y agoAh, I didn't see the part about //go:build
- _lvbh 3y agoWithout /: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
- s17n 3y agoThere isn’t really anything that you could actually use the old behavior for, any code that depends on it is probably wrong anyway.
- Cthulhu_ 3y agoNo 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)