From: "jeremyevans0 (Jeremy Evans)" <noreply@...>
Date: 2022-06-02T17:17:06+00:00
Subject: [ruby-core:108761] [Ruby master Feature#18815] instance_{eval, exec} vs Proc#>>

Issue #18815 has been updated by jeremyevans0 (Jeremy Evans).

Backport deleted (2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN)
Tracker changed from Bug to Feature

zverok (Victor Shepelev) wrote in #note-3:
> @jeremyevans0 I don't think it is a "bug", but maybe a nice feature to have

That makes sense.  Switching to feature request.

----------------------------------------
Feature #18815: instance_{eval,exec} vs Proc#>>
https://bugs.ruby-lang.org/issues/18815#change-97820

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
```ruby
measure = proc { p "self=#{self}"; size }
multiply = proc { '*' * _1 }

'test'.instance_eval(&measure)
# "self=test"
#  => 4

'test'.instance_eval(&measure >> multiply)
# "self=main"
# NameError (undefined local variable or method `size' for main:Object)
```

So, `Proc#>>` produces a proc which is not suitable for `instance_eval`/`instance_exec`. The same as the "naive" implementation:
```ruby
# Naive sequence
sequence = proc { measure.call.then(&multiply) }
```

...but is it possible to make the combination to behave like the first proc is not wrapped into an additional layer of indirection?.. Intuitively, it shouldn't be completely impossible.
```ruby
# What I meant actually:
intended = proc { size.then(&multilpy) }
"test".instance_eval(&intended)
# => "****"
```

The example is invented, the question is "whether this should work", not "how to solve this task with another approach".



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>