5 ms·

The “Loopvar” experiment looks like backward compatibility nightmare. As confusing as the existing behaviour could be, the new experiment is asking for trouble.

jjnoakes 3y ago
> no programs will change behavior due to simply adopting the new Go toolchain Seems like they thought about that. I think it's a good change.
philosopher1234 3y ago
It’s a breaking change, but rsc did very thorough testing of publicly available code and internal Google code and found essentially only bug fixes. But I think the risk is why this is an experiment and not a straight up change. Also, the new behavior would only be enabled on modules that are marked as Go 1.22 or above, not program globally, iiuc. So to me, this is very thoughtfully planned and unlikely to be any kind of nightmare
- deleted 3y ago
  [deleted]
icholy 3y ago
C# did the same thing in 5.0 https://ericlippert.com/2009/11/16/closing-over-the-loop-variable-considered-harmful-part-two/ https://ericlippert.com/2009/11/16/closing-over-the-loop-var...
- plorkyeran 3y ago
  When C# shipped this change I was working on a large C# codebase and we were very worried about this. After auditing the entire codebase and checking every for loop, we found two pre-existing bugs in code which expected the 5.0 behavior and zero places which relied on the old behavior. Everyone that I've ever talked to who went through the transition has a similar story. In practice no one even incidentally relied on the old behavior. Go rolling it out as an experimental opt-in feature is a good idea, but it'll probably turn out to be unnecessarily cautious and they could have gotten away with just unconditionally enabling it.
- tapirl 3y ago
  C# only did this on `foreach` loops, not on traditional `for` loops. Go plans to do this on both (`for-range` loops and traditional `for` loops).
masklinn 3y ago
Is it? The experiment is just that, a way to test your packages for breakage, the proposition to opt in via langfile is similar to Rust edition systems which work fine. Way back when C# actually went through that change unconditionally (LangVersion was not a thing yet), and there was barely any breakage.
latchkey 3y ago
Forgetting to add `foo := foo` in a for loop tends to be bigger trouble. =)
tsimionescu 3y ago
The existing behavior is extremely unlikely to be helpful, even accidentally. I will be shocked if anyone actually hits a problem related to this change. It may well fix more bugs than it introduces.
tapirl 3y ago
For `for-range` loops, it looks the benefits of this change are more than the drawbacks. For `for ...; ...; ...` loops, personally, I think the conclusion is the inverse. One breaking case: func main() { defer println() for counter, i := 0, 0; i < 3; i++ { defer func() { counter++ print(counter) }() } } It will print 111 when the change is made. More surprising cases: https://github.com/golang/go/issues/60078#issuecomment-1544324607 https://github.com/golang/go/issues/60078#issuecomment-15443...
- tedunangst 3y ago
  Why don't any of the examples of surprise breakage link to real code relying this behavior?
  - tapirl 3y ago
    why do you ask such a confusing question?
    - masklinn 3y ago
      The question seems completely straightforward.
      - tapirl 3y ago
        It is confusing that why such a question was asked. It shows the asker lacks of basic logical ability.
        yencabulator 3y ago
        The experiment changes behavior, nobody's contesting that. Does it change behavior in any scenario that matters?
        tapirl 3y ago
        As far as I know, no one has proved that it doesn't change behavior in any scenario that matters, including the proposal makers. Have you proved it?
kristianp 3y ago
For those wondering: https://github.com/golang/go/wiki/LoopvarExperiment https://github.com/golang/go/wiki/LoopvarExperiment

jjnoakes 3y ago

> no programs will change behavior due to simply adopting the new Go toolchain Seems like they thought about that. I think it's a good change.

philosopher1234 3y ago

It’s a breaking change, but rsc did very thorough testing of publicly available code and internal Google code and found essentially only bug fixes. But I think the risk is why this is an experiment and not a straight up change. Also, the new behavior would only be enabled on modules that are marked as Go 1.22 or above, not program globally, iiuc. So to me, this is very thoughtfully planned and unlikely to be any kind of nightmare

deleted 3y ago
[deleted]

icholy 3y ago

C# did the same thing in 5.0 https://ericlippert.com/2009/11/16/closing-over-the-loop-variable-considered-harmful-part-two/ https://ericlippert.com/2009/11/16/closing-over-the-loop-var...

plorkyeran 3y ago
When C# shipped this change I was working on a large C# codebase and we were very worried about this. After auditing the entire codebase and checking every for loop, we found two pre-existing bugs in code which expected the 5.0 behavior and zero places which relied on the old behavior. Everyone that I've ever talked to who went through the transition has a similar story. In practice no one even incidentally relied on the old behavior. Go rolling it out as an experimental opt-in feature is a good idea, but it'll probably turn out to be unnecessarily cautious and they could have gotten away with just unconditionally enabling it.
tapirl 3y ago
C# only did this on `foreach` loops, not on traditional `for` loops. Go plans to do this on both (`for-range` loops and traditional `for` loops).

masklinn 3y ago

Is it? The experiment is just that, a way to test your packages for breakage, the proposition to opt in via langfile is similar to Rust edition systems which work fine. Way back when C# actually went through that change unconditionally (LangVersion was not a thing yet), and there was barely any breakage.

latchkey 3y ago

Forgetting to add `foo := foo` in a for loop tends to be bigger trouble. =)

tsimionescu 3y ago

The existing behavior is extremely unlikely to be helpful, even accidentally. I will be shocked if anyone actually hits a problem related to this change. It may well fix more bugs than it introduces.

tapirl 3y ago

For `for-range` loops, it looks the benefits of this change are more than the drawbacks. For `for ...; ...; ...` loops, personally, I think the conclusion is the inverse. One breaking case: func main() { defer println() for counter, i := 0, 0; i < 3; i++ { defer func() { counter++ print(counter) }() } } It will print 111 when the change is made. More surprising cases: https://github.com/golang/go/issues/60078#issuecomment-1544324607 https://github.com/golang/go/issues/60078#issuecomment-15443...

tedunangst 3y ago
Why don't any of the examples of surprise breakage link to real code relying this behavior?
- tapirl 3y ago
  why do you ask such a confusing question?
  - masklinn 3y ago
    The question seems completely straightforward.
    - tapirl 3y ago
      It is confusing that why such a question was asked. It shows the asker lacks of basic logical ability.
      - yencabulator 3y ago
        The experiment changes behavior, nobody's contesting that. Does it change behavior in any scenario that matters?
        tapirl 3y ago
        As far as I know, no one has proved that it doesn't change behavior in any scenario that matters, including the proposal makers. Have you proved it?

kristianp 3y ago

For those wondering: https://github.com/golang/go/wiki/LoopvarExperiment https://github.com/golang/go/wiki/LoopvarExperiment