5 ms·

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

by campbel 3y ago

matthewmueller 3y ago
It's only enabled for modules that run Go 1.22 and higher
- badrequest 3y ago
  I also can't imagine a case where it is useful or even truly intended to rely on this behavior.
  - omginternets 3y ago
    Yeah it’s def a code smell …
  - ben0x539 3y ago
    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.
    - rsc 3y ago
      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.
      - kuchenbecker 3y ago
        If
  - Cthulhu_ 3y ago
    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.
infogulch 3y ago
> 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.
- 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 ago
    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.
  - ericpauley 3y ago
    No, it does not. Packages can compile using 1.22 and gain other benefits without opting into this change.
    - sixstringtheory 3y ago
      Ah, I didn't see the part about //go:build
      - _lvbh 3y ago
        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
  - s17n 3y ago
    There isn’t really anything that you could actually use the old behavior for, any code that depends on it is probably wrong anyway.
deleted 3y ago
[deleted]
minroot 3y ago
Some time spent with Go gives a strong indication that Go team always has backwards compatibility in mind
- jacquesm 3y ago
  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.
omeid2 3y ago
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.).
- wrs 3y ago
  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.
  - robertlagrant 3y ago
    Isn't that "working with future point releases", though? If I don't declare 1.22, am I not excluded from that point release?
    - ben0x539 3y ago
      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.
    - mrkstu 3y ago
      No, the compiler will revert to the original behavior, it only adopts the new behavior with the declaration.
    - skywhopper 3y ago
      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.
- freedomben 3y ago
omginternets 3y ago
Seems like yes, though hopefully that should be rare.
nerdponx 3y ago
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.
doctor_eval 3y ago
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.
skywhopper 3y ago
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.
beltsazar 3y ago
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 https://github.com/golang/go/issues/60078 [2] https://go.dev/doc/go1compat https://go.dev/doc/go1compat
baq 3y ago
You may also wonder how many would it fix if it wasn't hidden behind a flag?
tapirl 3y ago
A lots: https://twitter.com/go100and1/status/1690412229135601664 https://twitter.com/go100and1/status/1690412229135601664 https://twitter.com/go100and1/status/1690587305806057472 https://twitter.com/go100and1/status/1690587305806057472 https://twitter.com/go100and1/status/1690589791686119424 https://twitter.com/go100and1/status/1690589791686119424 https://twitter.com/go100and1/status/1690591234715492352 https://twitter.com/go100and1/status/1690591234715492352 https://twitter.com/go100and1/status/1690593184857145344 https://twitter.com/go100and1/status/1690593184857145344 https://twitter.com/go100and1/status/1691456732151889920 https://twitter.com/go100and1/status/1691456732151889920 Most of them are not mentioned in the proposal doc at all.

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

matthewmueller 3y ago

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

badrequest 3y ago
I also can't imagine a case where it is useful or even truly intended to rely on this behavior.
- omginternets 3y ago
  Yeah it’s def a code smell …
- ben0x539 3y ago
  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.
  - rsc 3y ago
    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.
    - kuchenbecker 3y ago
      If
- Cthulhu_ 3y ago
  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.

infogulch 3y ago

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

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

deleted 3y ago

[deleted]

minroot 3y ago

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

jacquesm 3y ago
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.

omeid2 3y ago

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

wrs 3y ago
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.
- robertlagrant 3y ago
  Isn't that "working with future point releases", though? If I don't declare 1.22, am I not excluded from that point release?
  - ben0x539 3y ago
    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.
  - mrkstu 3y ago
    No, the compiler will revert to the original behavior, it only adopts the new behavior with the declaration.
  - skywhopper 3y ago
    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.
freedomben 3y ago

omginternets 3y ago

Seems like yes, though hopefully that should be rare.

nerdponx 3y ago

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.

doctor_eval 3y ago

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.

skywhopper 3y ago

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.

beltsazar 3y ago

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 https://github.com/golang/go/issues/60078 [2] https://go.dev/doc/go1compat https://go.dev/doc/go1compat

baq 3y ago

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

tapirl 3y ago

A lots: https://twitter.com/go100and1/status/1690412229135601664 https://twitter.com/go100and1/status/1690412229135601664 https://twitter.com/go100and1/status/1690587305806057472 https://twitter.com/go100and1/status/1690587305806057472 https://twitter.com/go100and1/status/1690589791686119424 https://twitter.com/go100and1/status/1690589791686119424 https://twitter.com/go100and1/status/1690591234715492352 https://twitter.com/go100and1/status/1690591234715492352 https://twitter.com/go100and1/status/1690593184857145344 https://twitter.com/go100and1/status/1690593184857145344 https://twitter.com/go100and1/status/1691456732151889920 https://twitter.com/go100and1/status/1691456732151889920 Most of them are not mentioned in the proposal doc at all.