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.8 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 429741F463 for ; Tue, 24 Sep 2019 22:39:51 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 609EF120924; Wed, 25 Sep 2019 07:39:42 +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 54CDC120924 for ; Wed, 25 Sep 2019 07:39:40 +0900 (JST) Received: by filter0191p3mdw1.sendgrid.net with SMTP id filter0191p3mdw1-16881-5D8A9B2E-4B 2019-09-24 22:39:42.581580156 +0000 UTC m=+92377.081774886 Received: from herokuapp.com (unknown [54.157.43.252]) by ismtpd0058p1iad2.sendgrid.net (SG) with ESMTP id JicVKP1cTy22rv3Toq7Esw for ; Tue, 24 Sep 2019 22:39:42.502 +0000 (UTC) Date: Tue, 24 Sep 2019 22:39:42 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70626 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16178 X-Redmine-Issue-Author: Eregon X-Redmine-Issue-Assignee: matz X-Redmine-Sender: Eregon 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr38DIssktnRVJ0j0Yp6QV?= =?us-ascii?Q?XHn9gUGpPzyolPBy=2FjhavFdVhrw05J9G1K0if7n?= =?us-ascii?Q?hcNIO0WhSxLTpnpGtEW9aTGzWLYuTz6zgKZaX4K?= =?us-ascii?Q?tBrIqBBueiq3qlQp5DrLZ8QTNr+LXzNPb+U5olM?= =?us-ascii?Q?RaKk1T+7ktgIK=2FOcsgGpQItgx22vy6jKMDg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95071 Subject: [ruby-core:95071] [Ruby master Bug#16178] Numbered parameters: _1 should be the same as |x| and _0 should not exist 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 #16178 has been updated by Eregon (Benoit Daloze). It's all about definitions. How do we explain numbered parameters? Isn't `_1` the first parameter, as in `x` in `{ |x| }` and `x` in `{ |x,y| }`? And therefore `_2` the second parameter as in `y` in `{ |x,y| }`? Of course, `{ |x| x }` and `{ |x,y| x }` already have different semantics, so why should `{ _2; _1 }` not be different than `{ _1 }` ? I think that makes a lot of sense, is intuitive, and is very easy to explain. But the current semantics don't match that. How would we define the current semantics, without being very complex or confusing? ---------------------------------------- Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not exist https://bugs.ruby-lang.org/issues/16178#change-81704 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: * ruby -v: ruby 2.7.0dev (2019-09-24T12:57:54Z master 0e84eecc17) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- Currently on trunk: ```ruby array = ["string", 42, [1, 2]] array.map { |x| x * 2 } # => ["stringstring", 84, [1, 2, 1, 2]] array.map { _1 * 2 } # => ["stringstring", 84, 2] ``` Oops, this trivial code just lost data and completely ignored the element class! This is clearly contrary to intuition and is very dangerous. Using `_0` instead has the correct behavior but it's clear we use 1-based indexing for numbered parameters, and it doesn't solve that `_1` has dangerous behavior. Basically the current behavior is that `_0` is the same as `|x|` and `_1` is the same as `|x,|`. `|x,|` is almost never used in Ruby, and for good reasons, it just throws away data/information/the class of the object. Such a dangerous operation should only be done when it's explicit, and the trailing comma in `|x,|` shows that, but `_1` does not. So let's make `_1` be `|x|` and remove `_0`. I am going to be harsh, but this discussion has gone too long without any serious written argument for the current behavior: I believe it's irrational and irresponsible to have `_1` be `|x,|`, it's just going to lead to nasty bugs. Try to convince me otherwise. If not, in one week I want to apply this change. >From the discussion in https://bugs.ruby-lang.org/issues/15723#note-127 and in https://bugs.ruby-lang.org/issues/15708 Some reactions to this behavior in https://twitter.com/eregontp/status/1115318993299083265 -- https://bugs.ruby-lang.org/