Hacker News Reader

Comment by omeid2 | Hacker News Reader

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

View on HN

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.

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.

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.

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)

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.

Reply on news.ycombinator.com