Hacker News Reader

Comment by campbel | Hacker News Reader

Won't this end up breaking programs that depend on the current behavior?

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

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

I don't know why you're being down voted, but it is actually breaking the Go1 compat promise. Which says:

    It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. At some indefinite point, a Go 2 specification may arise, but until that time, Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).

Note the word “programs”, not “files”. If your program doesn’t declare go 1.22 in its go.mod, it will continue to work (or not work!), unchanged.

Isn't that "working with future point releases", though? If I don't declare 1.22, am I not excluded from that point release?

I assume that if compiling with 1.22 or later, you still get all the benefits from that version like other new features, bug fixes or perf improvements, just not this particular change.

No, the compiler will revert to the original behavior, it only adopts the new behavior with the declaration.

This has all been addressed in the proposal. The research was done and this change will impact so few projects that it’s worth making a technical exception to the compatibility promise to fix a real design flaw.

I upvoted the question to offset one of the downs because I agree it's a fair question. However I would guess the downvotes are because TFA addressed this issue directly and comprehensively, so it's a clear "I didn't read the article" indicator :-) Possibly also because the downvoters can't imagine a scenario where this would be desirable behavior (i.e. it's always a bug)

Yeah its fair, I didn't closely read that section. Although, I'm not entirely convinced the approach is safe, maybe its worth it to fix such a common pitfall.

But if it’s a bug, then the logic to not compile future versions is wrong, IMO. If it’s a feature change, then such logic would make sense.

I don't mind.

Yeah, I thought this kind of change wouldn't happen because of this promise.

I think it was downvoted precisely because of that. It's a bit of a contentious issue.

And they do. You can specify the precise logic to use on a per-file basis.

In a previous blog post they basically said they will never make a Go 2, and also addressed a lot of things about compatibility:

https://go.dev/blog/compat

In particular they said:

> The end of the document warns, “[It] is impossible to guarantee that no future change will break any program.” Then it lays out a number of reasons why programs might still break.

> For example, it makes sense that if your program depends on a buggy behavior and we fix the bug, your program will break. But we try very hard to break as little as possible and keep Go boring.

> In a previous blog post they basically said they will never make a Go 2

No, they didn't say that, they said it wouldn't be backwards-incompatible with Go 1. Relevant quote:

> [...] when should we expect the Go 2 specification that breaks old Go 1 programs?

> The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened.

No, it doesn't break the promise; "Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.)."

You can install Go 1.22 and your program will compile and run as-is. That's the promise. If however you opt-in to the changed for loop behaviour by adjusting your go.mod, the onus is on you to update your program accordingly.

It's only a backwards incompatible change if the developer makes a backwards incompatible change by updating the configured target version.

(I'm aware I'm probably being pedantic here, I understand the language used seems to imply you can just set it to v1.22 and it works but it's a bit more specific)

To add to the other comments, in the run-up to go1.21 they talked about how they’d analysed a very large corpus of Go code to see what would be affected, and it was a very very small number.

I remember thinking that the number of people who have created inadvertent bugs due to this design (myself included) would be significantly greater than the number of people affected by the fix.

The original proposal for this change went into great detail about the research they did into existing uses of this syntax. In my memory, they found vanishingly few cases in the Google codebase or GitHub code where the change would violate the expected behavior. The decision to break the backwards compatibility here came only after determining how few codebases would be affected and developing a mechanism in Go itself (the version specification in go.mod) to require actively modifying the code to build with the new behavior.

A lots:

https://twitter.com/go100and1/status/1690412229135601664

https://twitter.com/go100and1/status/1690587305806057472

https://twitter.com/go100and1/status/1690589791686119424

https://twitter.com/go100and1/status/1690591234715492352

https://twitter.com/go100and1/status/1690593184857145344

https://twitter.com/go100and1/status/1691456732151889920

Most of them are not mentioned in the proposal doc at all.

Python has the same problem (to the extent that it's actually a problem, which you might or might not agree with), and this is the #1 reason they won't change it.

It's only enabled for modules that run Go 1.22 and higher

I also can't imagine a case where it is useful or even truly intended to rely on this behavior.

Yeah it’s def a code smell …

Yeah I don't think it's so much "we explicitly rely on this behavior, how dare you change this" as "somewhere in our mountains of maintenance-mode code that haven't seen the sun shine through an editor window in years, this behavior cancels out another bug that we never noticed". Tooling should be able to detect when code relies on this, but it's still gonna cost some non-zero amount of developer effort to touch ancient code and safely roll out a new version if it needs to be actively addressed.

If you have tests and they break with GOEXPERIMENT=loopvar, then there is a new tool that will tell you exactly which loop is causing the breakage. That's a post for a few weeks from now.

Neither can I, but there may be cases of code accidentally relying on it - there's an adage that I forgot the name of that says just that, and I think compiler manufacturers are the most aware of that adage.

Some time spent with Go gives a strong indication that Go team always has backwards compatibility in mind

They do. Go has avoided most of the pitfalls that other language eco-systems have fallen for over the years (backwards compatibility issues, soft forks masquerading as language improvements, re-booting the whole language under the same name, aggressively pushing down on other languages etc). They've done remarkably well in those respects, and should deserve huge credit for it.

Yes, the loopvar change will break some programs, and hence the compatibility promise. But the Go team argues that the change will fix much more programs than it will break [1].

This makes me wonder, though, what guarantees that a similar breaking change won't ever happen again in the future? If any change with #(programs fixed) >> #(programs broken) is accepted, we might as well remove the compatibility promise page [2].

---

[1] https://github.com/golang/go/issues/60078

[2] https://go.dev/doc/go1compat

You may also wonder how many would it fix if it wasn't hidden behind a flag?

Seems like yes, though hopefully that should be rare.

Reply on news.ycombinator.com