Issue #14390 has been updated by zverok (Victor Shepelev).


@shyouhei the point is in gradual enchancing Ruby's approach to functional/declarative chaining.

Let's look at this example:

```ruby
(1..3).each(&method(:print))
(1..3).each { |i| print i }
```

The second, in fact, is _shorter_, but (at least for me) the first somehow feels more "right" even in this case: for example, because it is more DRY (no "define i вк immediately use i"); but also, it forces to structure code flow clearly (e.g. instead of hairballs of large blocks chained, I tend to think about code structuring in "processed by this method, then processed by that method").

Now, when the basic usability of `&method(...)` is aknowledged by some, when it would be shortened (I hope), it will be an awesome tool of writing short and clean code. 

Also, I believe that some room of optimization is present here, e.g. if some proc "knows" (and, at C level, it knows) it is just a Method, then it can be passed and called with less overflow.

Closer to the topic of current issue: 

The baseline is this:
```ruby
map{|i| i.dig(:foo :bar, :baz) }
```
And looking at things like `map(&:size)`, lot of people invent things like:
```ruby
.map(&:dig(:foo, :bar, :baz))
# or
.map(&:dig.(:foo, :bar, :baz))
```
...which is interesting but somehow "spheric in a vacuum": what is this syntax? whose responsibility is to maintain it? How should it be read and parsed?

So, what I am trying to think about, is not the necessary _shorter_ code, but conceptually more clean. If the concepts are there, it can be shortened to a special syntax later (like `&method(:foo)` вк `&.:foo` is planned currently).

So, my idea was (I am not sure about it, but I believe that at least introduction of `UnboundMethod#to_proc` would not _harm_ anybody or anything) that 

```ruby
map(&Hash.instance_method(:dig).rcurry[:foo :bar, :baz])
```
...is not a _better_ way of doing things, just a way that _can_ be made available, to see what optimization and code style techniques can emerge.

It is somehow "logical" to say that `.map(&:dig.(:foo, :bar, :baz))` is "rendered" as "call instance method with thouse arguments bound to it".

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

* 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:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>