10 ms·

I mean, that is the point of a closure. The name refers to closing over its environment. In terms of implementation, the closure needs to keep a reference to i

• simonask 1y ago
  That's what I'm saying: In Ruby, you can transplant code from a closure out of its lexical scope and evaluate it as if it was defined in a different environment. Should you ever do this? No. But you can. :-)
  • vidarh 1y ago
    My point is that this isn't "reckless" - it's a core part of the value of a closure. We do this regularly enough in Ruby - usually with lambda rather than proc/blocks because of the return semantics, but you can do it just as safely with proc/blocks as long as you don't call "return" within them (there's no reason to, on the other hand). It's a way of e.g. building generator methods that returns distinct callable objects without constructing a whole class. In that case the closure environment effectively becomes the instance variables.
    • simonask 1y ago
      It is the opposite of what a closure typically means, because it is precisely not “closing” over its lexical scope. It’s an interesting feature to be sure, and it enables some really beautiful things, but it also enables some incredibly difficult bugs.