Thanks for the context, I understand your point about consistency. So this case ```ruby 42.tap { |x| x = x; p x } ``` Works because by the time we reach `x = x`, the block parameter already declared `x` as a local and so it doesn...vinistock (Vinicius Stock)
No, I don't mean all variables. However, the `it` case feels unintuitive because `it` refers to the first argument of the block. Take this other example here: ```ruby 42.tap { it = it; p it } 42.tap { |x| x = x; p x } ``` To me,...vinistock (Vinicius Stock)
Bringing my comment from the [pull request](https://github.com/ruby/prism/pull/3604) here. Reviewed with [@AMomchilov](https://bugs.ruby-lang.org/users/51722) We wonder if Prism's current behaviour is more intuitive for developers. In...vinistock (Vinicius Stock)
> I can't get your point. > ... If we create a method using `define_method`, it only exists in the Ractor that made the invocation. Trying to invoke that method from a different Ractor throws an error (something like `defined in another...vinistock (Vinicius Stock)
Regarding the examples, they are over simplified for the sake of understanding. Sure, you wouldn't need `define_method` in those cases. I'm talking more generally when someone needs to capture a block or surrounding locals to use in `def...vinistock (Vinicius Stock)
Invoking `define_method` will capture the surrounding environment, making sure we have access to anything defined in that surrounding scope. However, that’s not always necessary. There are uses for `define_method` where the surrounding e...vinistock (Vinicius Stock)
[Link for GitHub PR containing the fix](https://github.com/ruby/ruby/pull/4755) Ractors may invoke `rb_objspace_reachable_objects_from` when yielding values back to the main-Ractor. If this occurs during a sweeping pass of the GC, the...vinistock (Vinicius Stock)
vinistock (Vinicius Stock)06:41 PM Ruby Bug #21139: Prism and parse.y parses `it = it` differently