[ruby-core:87157] [Ruby trunk Feature#14390] UnboundMethod#to_proc

Issue #14390 has been updated by shyouhei (Shyouhei Urabe).


Thank you for the explanation. So as far as I understand what you want to do is not just UnboundMethod#to_proc, but a lot more.  Seems you are drawing a quite big picture covering structure of code flows. So far I see this UnboundMethod#to_proc feature itself is not that useful, but understand the motivation behind this proposal.

----------------------------------------
Feature #14390: UnboundMethod#to_proc
https://bugs.ruby-lang.org/issues/14390#change-72147

* Author: zverok (Victor Shepelev)
* Status: Feedback
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
I believe that it could be somewhat useful to have UnboundMethod converted to proc (accepting the object to bind to, as a first argument).

Practical(ish) example, paired with [Proc#rcurry](https://bugs.ruby-lang.org/issues/11161) proposal:

```ruby
URLS.
  map(&Faraday.method(:get).rcurry[some_get_param: 'value']).
  map(&JSON.method(:parse).rcurry[symbolize_names: true]).
  map(&Hash.instance_method(:dig).rcurry[:foo :bar, :baz])
```

It is somewhat more verbose than a lot of alternative proposals for "shorthand of &method call with arguments", yet requires no changes in parser or language design. With some future shortcuts/operators for `#method` and `#instance_method` it can even become pretty short and look like an "idiom".

PS: For the reference, shorthand that was proposed and rejected several times (see #6483, #4146):

```ruby
...map(&:dig(:foo :bar, :baz))
```

As it is indeed looks much shorter than my proposal, it raises a lot of question about what is that `:dig(:foo :bar, :baz)` and how it should be parsed and whether it can appear outside of `&`-calls.



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

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>