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=-3.6 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham 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 BB2E3211B4 for ; Sat, 12 Jan 2019 11:35:14 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id BE99B12197B; Sat, 12 Jan 2019 20:35:11 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 5C8FE1218D0 for ; Sat, 12 Jan 2019 20:35:09 +0900 (JST) Received: by filter0070p3mdw1.sendgrid.net with SMTP id filter0070p3mdw1-8207-5C39D0EA-26 2019-01-12 11:35:06.652046494 +0000 UTC m=+42028.300444894 Received: from herokuapp.com (unknown [54.205.103.107]) by ismtpd0017p1iad2.sendgrid.net (SG) with ESMTP id co7UOlumTxCd6xB0IlkJPA for ; Sat, 12 Jan 2019 11:35:06.511 +0000 (UTC) Date: Sat, 12 Jan 2019 11:35:08 +0000 (UTC) From: nobu@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66473 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15428 X-Redmine-Issue-Author: zverok X-Redmine-Sender: nobu 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?q8Dly+pU2+3ektTtZVXgZtbJPXwqo7p86jCsvYTW4BzyvlT0FoErWyj5eizC=2Fl?= =?us-ascii?Q?6AmEI2qKW5LC=2F3EDRGK4uFliYezRJNJkS3senmO?= =?us-ascii?Q?M2Fz72CKHDGFI2p+Ryvnpf2zc8GeVGu=2FZeUKPxo?= =?us-ascii?Q?sjgGfplS96ROR23USXPbFpRLnmWuq9DLxY4GogE?= =?us-ascii?Q?EUYgLzU4wV1cF+7FThCl4nIDazQQFOMXG1w=3D=3D?= X-ML-Name: ruby-core X-Mail-Count: 91039 Subject: [ruby-core:91039] [Ruby trunk Bug#15428] Refactor Proc#>> and #<< 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 #15428 has been updated by nobu (Nobuyoshi Nakada). Sorry, I was going to reopen this after r66769, but have forgotten. > Currently, it is the **only** place in Ruby where coercing argument to `Proc` is done with `#call` method. These methods do not coerce argument, but just expect a method on it. > 1. change `#>>` and `#<<` to use `#to_proc` `#to_proc` is not an implicit conversion method, as it needs the specific syntax, `&`. > 2. state that `#call` from now on has a special meaning in Ruby It is a usual case that a method may expect its argument to have particular method(s), e.g., `String#+` expects `#to_str` on non-string argument. ---------------------------------------- Bug #15428: Refactor Proc#>> and #<< https://bugs.ruby-lang.org/issues/15428#change-76260 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- #6284 introduced `Proc#>>` and `Proc#<<`, but the requirements to the argument is totally inconsistent with ANY other place in Ruby. Currently, it is the **only** place in Ruby where coercing argument to `Proc` is done with `#call` method. Everywhere else it is done with `#to_proc`, and `#call` method never had any special significance except for `.()` sugar. I believe there are two possible actions: 1. change `#>>` and `#<<` to use `#to_proc` (which will give Symbols composability for free), **or, alternatively** 2. state that `#call` from now on has a special meaning in Ruby and probably decide on other APIs that should respect it (for example, auto-define `#to_proc` on any object that has `#call`) Either is OK, the current situation is not. PS: One more problem (that probably should be discussed separately) is that check for `#call` existence is performed pretty late, which can lead to this kind of errors: ```ruby # At code loading time: # I erroneously thought this is correct. It is not, but the line would perform without # any error. PROCESSOR = JSON.method(:parse) >> :symbolize_keys # Later, in runtime: '{"foo": "bar"}'.then(&PROCESSOR) # NoMethodError (undefined method `call' for :symbolize_keys:Symbol) ``` **UPD 2018-12-29:** As this ticket was ignored prior to 2.6 release, I rewrote it in an "actionable" instead of "question" manner. -- https://bugs.ruby-lang.org/