12 ms·

The C# language team encountered this as well, after introducing lightweight closures in C# 4.0 it quickly became apparent that this was a footgun. Users almost

The C# language team encountered this as well, after introducing lightweight closures in C# 4.0 it quickly became apparent that this was a footgun. Users almost always used loop variables incorrectly, and C# 5.0 made the breaking change. Eric Lippert has a wonderful blog on the "why" from their perspective: https://ericlippert.com/2009/11/12/closing-over-the-loop-variable-considered-harmful-part-one/ https://ericlippert.com/2009/11/12/closing-over-the-loop-var... I had a bit of trouble finding the original C# 5 announcement; that's hopefully not been lost in the (several?) blog migrations on the Microsoft domain since 2012.

jerf 3y ago
jaredpar on the C# team offered the very first comment on the Github issue for this proposal: https://github.com/golang/go/discussions/56010 https://github.com/golang/go/discussions/56010 I think it played a large part in helping get past the default-deny that any language change proposal should have. The other big one for me was the scan done over the open source code base and the balance of bugs fixed versus created.
- em-bee 3y ago
  as soon as i saw mention of c# going through the same thing, i realized that this was discussed before: https://news.ycombinator.com/item?id=33160236 https://news.ycombinator.com/item?id=33160236
nerdponx 3y ago
Meanwhile Python has received this same feature request many times over the years, and the answer is always that it would break existing code for little major benefit https://discuss.python.org/t/make-lambdas-proper-closures/10553 https://discuss.python.org/t/make-lambdas-proper-closures/10... Given how much of an uproar there was over changing the string type in the Python 2 -> 3 transition, I can't imagine this change would ever end up in Python before a 4.0. Cue someone arguing about how bad Python is because it won't fix these things, and then arguing about how bad Python is because their scripts from 2003 stopped working...
- sneak 3y ago
  Somehow, Go managed to not break old code and also fix the problem. I think this is a good case of Python not fixing things, given that a fix exists that solves both problems.
  - pcl 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.
    - nerdponx 3y ago
      Right, and Go has the luxury of being a compiler that generates reasonably portable binaries, while Python requires the presence of an interpreter on the system at run time.
      - josephg 3y ago
        The same trick would work with python just as well. There’s nothing about Python’s status as an interpreter which would stop them from adding a python semantic version somewhere in each python program - either in a comment at the top of each source file or in an adjacent config file. The comment could specify the version of python’s semantics to use, which would allow people to opt in to new syntax (or opt out of changes which may break the code in the future). Eg # py 3.4
        Cthulhu_ 3y ago
        Yeah, it would just mean that the interpreter - just like the Go compiler - would need to have the equivalent of "if version > 3.4 do this, else do that". Which is fine for a while, but I can imagine it adds a lot of complexity and edge cases to the interpreter / compiler. Which makes me think that a Go 2.0 or Python 4 will mainly be about removing branches and edge cases from the compiler more than making backwards-incompatible language changes.
tester756 3y ago
It is crazy that such behaviour even gets deployed It is so unintuitive...
- wahern 3y ago
  It's unintuitive to users of the language, but it's very intuitive from the perspective of those implementing the language. Everybody seems to make this mistake. Lua 5.0 (2003) made this mistake, but they fixed it in Lua 5.1 (2006). (Lua 5.0 was the first version with full lexical scoping.)
  - tester756 3y ago
    >It's unintuitive to users of the language, but it's very intuitive from the perspective of those implementing the language. It sounds like a lack of dogfooding, lack of review?
    - catach 3y ago
      To the degree the the implementers are also users they carry their implementer understanding into their use. Dogfooding doesn't help when your understanding doesn't match that of your users.
    - skywhopper 3y ago
      The problem is that the error conditions are relatively rare. Most of the time it doesn’t break anything. So even with dogfooding you can miss it or not see it as a problem early on. But after 10 years of evidence that it was a mistake, that it’s almost never intended, and the fix won’t break much if anything, it’s time to fix it.
    - masklinn 3y ago
      No, it’s just an obvious behaviour when you understand how the language works.
      - tester756 3y ago
hinkley 3y ago
Java also had this problem with anonymous classes. The solution is usually to introduce a functor. Being pass-by-value, it captures the state of the variables at its call time, which helps remove some ambiguity in your code. If you try to do something weird with variable capture, then any collections you accumulate data into (eg, for turning an array into a map), will behave differently than any declared variables. Go is trying to thread the needle by only having loop counters work this way. But that still means that some variables act weird (it's just a variable that tends to act weird anyway). And I wonder what happens when you define multiple loop variables, which people often do when there will be custom scanning of the inputs.
- eru 3y ago
  Which of the various meanings of the word 'functor' are you using here?
  - hinkley 3y ago
    Function that returns a function. You pass your counter into the function, it returns a function that remembers the original value, not the value as it keeps iterating later on in the caller.
    - eru 3y ago
      That's just a higher order function? That's an interesting definition. I thought you would either go with https://en.wikipedia.org/wiki/Functor_(functional_programming) https://en.wikipedia.org/wiki/Functor_(functional_programmin... or with https://en.wikipedia.org/wiki/Function_object https://en.wikipedia.org/wiki/Function_object https://en.wikipedia.org/wiki/Functor_(disambiguation) https://en.wikipedia.org/wiki/Functor_(disambiguation) has a few more choices, but doesn't seem to have yours.
      - Sharlin 3y ago
        Functor must be one of the worst overloaded terms in all of computing.
deleted 3y ago
[deleted]
pornel 3y ago
JS also had this problem and introduced for(let) loops.
za3faran 3y ago
Yet in typical golang fashion of not learning from previous languages, they chose to ignore this behavior, only to go back and try to fix it later.

jerf 3y ago

jaredpar on the C# team offered the very first comment on the Github issue for this proposal: https://github.com/golang/go/discussions/56010 https://github.com/golang/go/discussions/56010 I think it played a large part in helping get past the default-deny that any language change proposal should have. The other big one for me was the scan done over the open source code base and the balance of bugs fixed versus created.

em-bee 3y ago
as soon as i saw mention of c# going through the same thing, i realized that this was discussed before: https://news.ycombinator.com/item?id=33160236 https://news.ycombinator.com/item?id=33160236

nerdponx 3y ago

Meanwhile Python has received this same feature request many times over the years, and the answer is always that it would break existing code for little major benefit https://discuss.python.org/t/make-lambdas-proper-closures/10553 https://discuss.python.org/t/make-lambdas-proper-closures/10... Given how much of an uproar there was over changing the string type in the Python 2 -> 3 transition, I can't imagine this change would ever end up in Python before a 4.0. Cue someone arguing about how bad Python is because it won't fix these things, and then arguing about how bad Python is because their scripts from 2003 stopped working...

sneak 3y ago
Somehow, Go managed to not break old code and also fix the problem. I think this is a good case of Python not fixing things, given that a fix exists that solves both problems.
- pcl 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.
  - nerdponx 3y ago
    Right, and Go has the luxury of being a compiler that generates reasonably portable binaries, while Python requires the presence of an interpreter on the system at run time.
    - josephg 3y ago
      The same trick would work with python just as well. There’s nothing about Python’s status as an interpreter which would stop them from adding a python semantic version somewhere in each python program - either in a comment at the top of each source file or in an adjacent config file. The comment could specify the version of python’s semantics to use, which would allow people to opt in to new syntax (or opt out of changes which may break the code in the future). Eg # py 3.4
      - Cthulhu_ 3y ago
        Yeah, it would just mean that the interpreter - just like the Go compiler - would need to have the equivalent of "if version > 3.4 do this, else do that". Which is fine for a while, but I can imagine it adds a lot of complexity and edge cases to the interpreter / compiler. Which makes me think that a Go 2.0 or Python 4 will mainly be about removing branches and edge cases from the compiler more than making backwards-incompatible language changes.

tester756 3y ago

It is crazy that such behaviour even gets deployed It is so unintuitive...

wahern 3y ago
It's unintuitive to users of the language, but it's very intuitive from the perspective of those implementing the language. Everybody seems to make this mistake. Lua 5.0 (2003) made this mistake, but they fixed it in Lua 5.1 (2006). (Lua 5.0 was the first version with full lexical scoping.)
- tester756 3y ago
  >It's unintuitive to users of the language, but it's very intuitive from the perspective of those implementing the language. It sounds like a lack of dogfooding, lack of review?
  - catach 3y ago
    To the degree the the implementers are also users they carry their implementer understanding into their use. Dogfooding doesn't help when your understanding doesn't match that of your users.
  - skywhopper 3y ago
    The problem is that the error conditions are relatively rare. Most of the time it doesn’t break anything. So even with dogfooding you can miss it or not see it as a problem early on. But after 10 years of evidence that it was a mistake, that it’s almost never intended, and the fix won’t break much if anything, it’s time to fix it.
  - masklinn 3y ago
    No, it’s just an obvious behaviour when you understand how the language works.
    - tester756 3y ago

hinkley 3y ago

Java also had this problem with anonymous classes. The solution is usually to introduce a functor. Being pass-by-value, it captures the state of the variables at its call time, which helps remove some ambiguity in your code. If you try to do something weird with variable capture, then any collections you accumulate data into (eg, for turning an array into a map), will behave differently than any declared variables. Go is trying to thread the needle by only having loop counters work this way. But that still means that some variables act weird (it's just a variable that tends to act weird anyway). And I wonder what happens when you define multiple loop variables, which people often do when there will be custom scanning of the inputs.

eru 3y ago
Which of the various meanings of the word 'functor' are you using here?
- hinkley 3y ago
  Function that returns a function. You pass your counter into the function, it returns a function that remembers the original value, not the value as it keeps iterating later on in the caller.
  - eru 3y ago
    That's just a higher order function? That's an interesting definition. I thought you would either go with https://en.wikipedia.org/wiki/Functor_(functional_programming) https://en.wikipedia.org/wiki/Functor_(functional_programmin... or with https://en.wikipedia.org/wiki/Function_object https://en.wikipedia.org/wiki/Function_object https://en.wikipedia.org/wiki/Functor_(disambiguation) https://en.wikipedia.org/wiki/Functor_(disambiguation) has a few more choices, but doesn't seem to have yours.
    - Sharlin 3y ago
      Functor must be one of the worst overloaded terms in all of computing.

deleted 3y ago

[deleted]

pornel 3y ago

JS also had this problem and introduced for(let) loops.

za3faran 3y ago

Yet in typical golang fashion of not learning from previous languages, they chose to ignore this behavior, only to go back and try to fix it later.