Issue #14390 has been updated by shevegen (Robert A. Heiler). > Ugh, seems it duplicates answer-less #10879. It can probably be referenced to the other report, and your issue here closed (or the other one; I think it does not matter which one). Some issues are unanswered but this does not necessarily mean that they are not discussed - just sometimes that they may have lower priority or go "under the radar" as a result. My suggestion would be - if the issue is important to you, and I somewhat agree with you here (primarily because I think it would be nice to be able to have UnboundMethod have to_proc too, simply due to versatility alone, also because it's kind of nice to be able to detach methods, fiddle around with them, then attach them back to something... a bit like LEGO blocks for kids :D), then you can try to have it registered for the next ruby developer meeting (the one for january already was only some hours ago, so you may have to wait for february; though matz can of course decide pro/con at any moment in time, but he often prefers some discussion for various reasons - see the backtick situation for 3.0). Anyway, before I write too much, I think it may be better and easier to provide links: Wiki to keep track of the developer meetings: https://bugs.ruby-lang.org/projects/ruby/wiki/Main Latest developer meeting in January 2018: https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20180124Japan Some discussion results of that meeting (not sure if everything has been logged but matz has said several things about some of the issues discussed there): https://docs.google.com/document/d/1q7GaG5KOy5qEKmOAeVucI4CbvYx-nQnSQSfSzyN-9EM/edit Biggest one is probably when MJIT will be merged. :) Anyway, if you think that your suggestion is important, I think a ruby core developer may add your issue to the list for the upcoming meeting. That way we may get matz' opinion on it eventually - and "two" issues could be approved or rejected at the same time! :D (Actually, I think your desscription here is better than the one given in https://bugs.ruby-lang.org/issues/10879 ) ---------------------------------------- Feature #14390: UnboundMethod#to_proc https://bugs.ruby-lang.org/issues/14390#change-69760 * Author: zverok (Victor Shepelev) * Status: Open * 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>