From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 7A06E1F45A for ; Wed, 14 Aug 2019 08:37:29 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 98FA1120AD2; Wed, 14 Aug 2019 17:37:21 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 9CE91120AD1 for ; Wed, 14 Aug 2019 17:37:19 +0900 (JST) Received: by filter0039p3iad2.sendgrid.net with SMTP id filter0039p3iad2-28013-5D53C841-31 2019-08-14 08:37:21.837073619 +0000 UTC m=+1603233.564375717 Received: from herokuapp.com (unknown [54.224.29.177]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id 2QP1VSwzTOCddqNYjMIPdw for ; Wed, 14 Aug 2019 08:37:21.677 +0000 (UTC) Date: Wed, 14 Aug 2019 08:37:21 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 69892 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16102 X-Redmine-Issue-Author: sawa X-Redmine-Sender: shevegen X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0wyzHKfAmfZw8+D9HEh+R?= =?us-ascii?Q?sYU9lnM=2FCs4pFNmYQsVkACJLUi1c9SHyx400Z2B?= =?us-ascii?Q?=2FofKWGgzlOkpC=2Flj+mhNtvFhdC40NC6kPOyJtL+?= =?us-ascii?Q?RVsGKErV0LnHsUUXg0T4ziXplvD5gvG2NIGwnbh?= =?us-ascii?Q?SU5qRmkzgPrW+vGgmYwCMFzJAYGYfpzAJiA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94345 Subject: [ruby-core:94345] [Ruby master Feature#16102] `Symbol#call` X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16102 has been updated by shevegen (Robert A. Heiler). I have no particular pro/con opinion on the suggested functionality here itself. In my opinion, this is mostly a design consideration for how "useful" matz wants to see symbols being used in ruby. (This may not be directly related to the comment here, but more generally in how simple, complex or useful matz may want to see symbols.) On a side note, it is (to me) interesting that sawa is not the only one with somewhat related ideas in this regard, as he has pointed out via mentioning https://bugs.ruby-lang.org/issues/12115. :) ---------------------------------------- Feature #16102: `Symbol#call` https://bugs.ruby-lang.org/issues/16102#change-80748 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Since symbols have a `to_proc` method, it is natural to expect that they would appear in a method chain like: ```ruby :some_symbol.to_proc.call(...) ``` In fact, I have use cases like this: ```ruby arrays = [["a", "b"], ["c"], ["d", "e"]] hashes = [{"a" => 1}, {"b" => 2, "c" => 3}, {"d" => 4, "e" => 5}] :product.to_proc.(*arrays) # => [["a", "c", "d"], ["a", "c", "e"], ["b", "c", "d"], ["b", "c", "e"]] :zip.to_proc.(*arrays) # => [["a", "c", "d"], ["b", nil, "e"]] :union.to_proc.(*arrays) # => ["a", "b", "c", "d", "e"] :merge.to_proc.(*hashes) # => {"a"=>1, "b"=>2, "c"=>3, "d"=>4, "e"=>5} ``` I request `Symbol#call` to be defined, which would implicitly call `to_proc` on the receiver and then the conventional `Proc#call` on the result. Then, I can do: ```ruby :product.(*arrays) # => [["a", "c", "d"], ["a", "c", "e"], ["b", "c", "d"], ["b", "c", "e"]] :zip.(*arrays) # => [["a", "c", "d"], ["b", nil, "e"]] :union.(*arrays) # => ["a", "b", "c", "d", "e"] :merge.(*hashes) # => {"a"=>1, "b"=>2, "c"=>3, "d"=>4, "e"=>5} ``` This would solve what proposals #6499, #6727, #7444, #8970, #11262 aim to do. Notice that proposals #12115 and #15301 ask for `Symbol#call`, but they ask for different things (a method that returns a proc), and are irrelevant to the current proposal. -- https://bugs.ruby-lang.org/