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.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY 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 96A7B1F4B4 for ; Thu, 1 Apr 2021 00:53:46 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 7A420120AD7; Thu, 1 Apr 2021 09:52:42 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id B085A120AD6 for ; Thu, 1 Apr 2021 09:52:40 +0900 (JST) Received: by filterdrecv-p3iad2-7d7c446bd4-g2w98 with SMTP id filterdrecv-p3iad2-7d7c446bd4-g2w98-19-60651991-2B 2021-04-01 00:53:37.513814679 +0000 UTC m=+714032.079555317 Received: from herokuapp.com (unknown) by ismtpd0167p1iad2.sendgrid.net (SG) with ESMTP id Ll5SdelqRJ69JQtdCt_xiw for ; Thu, 01 Apr 2021 00:53:37.483 +0000 (UTC) Date: Thu, 01 Apr 2021 00:53:37 +0000 (UTC) From: zn@mbf.nifty.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79180 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17768 X-Redmine-Issue-Author: mame X-Redmine-Sender: znz 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?n1sTxITOo+ZjMAfipLAmrNXkJTNL1mhwAgtk5LyQ2vg3wLtCQflpd5frXxhk0F?= =?us-ascii?Q?hSx1KIXqt+onPs7qaaIwfzjVc8Eh460Tm1LqSsy?= =?us-ascii?Q?d3HmeWqrRCMipeRa2itFePKK899U8CnogFeMRYS?= =?us-ascii?Q?iGdU9ONWvAJzJu3oBi4QdIagjOmN24MCa3eGQQ1?= =?us-ascii?Q?Q8bt2ap8ZgRSB01m17prT9kU5QwpDa5AbeTbnZT?= =?us-ascii?Q?40p0FyxHpIvH9B6vU=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103137 Subject: [ruby-core:103137] [Ruby master Feature#17768] Proposal: Downward assignments 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 #17768 has been updated by znz (Kazuhiro NISHIYAMA). I think this syntax is not `irb` friendly. ---------------------------------------- Feature #17768: Proposal: Downward assignments https://bugs.ruby-lang.org/issues/17768#change-91209 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- Rightward assignments have been introduced since 3.0. To be honest, I'm not a big fan of the syntax because it does not add a new dimension to Ruby. Why don't we bring Ruby to the next dimension? ## Proposal I propose "downward assignments". ``` p(2 * 3 * 7) #=> 42 ^^^^^var p var #=> 6 ``` This new syntax intercepts the intermediate value of a subexpression. In the above example, the subexpression `2 * 3` is captured to `var`. You can capture multiple subexpressions in one line. ``` puts("Hello" + "World") #=> HelloWorld ^^^^^^^x ^^^^^^^y p x #=> "Hello" p y #=> "World" ``` This proposal solves some long-standing issues in Ruby. ## Use case 1 Everyone has written the following code. ``` while (line = gets) != nil p line end ``` This code is not so bad, but there's something that has been on my mind: is it really good to put an assignment into a condition expression? I'm afraid that it makes the loop condition unclear. Unfortunately, it is difficult to keep the condition clear in Ruby. If the assignment is removed from the condition, the code becomes even more unclear as follows. ``` while true line = gets break if line == nil p line end ``` By using my proposal, you can make the condition crystal-clear. ``` while gets != nil ^^^^line p line end ``` ## Use case 2 Consider that we want to get from an array the last element that meets a condition. ``` ary = [1, 2, 3, 4, 5] ary.each {|elem| found = elem if elem.even? } p found #=> 4 ``` As you know, this code does not work. We need to add `found = nil` to declare the variable "found" in the outer scope. But this is unarguably dirty. My proposal allows to make the code very straightforward. ``` ary = [1, 2, 3, 4, 5] ary.each {|elem| elem if elem.even? } ^^^^found p found #=> 4 ``` ## Use case 3 When writing a constructor, we need to write each field name whopping three times. ``` class C def initialize(foo, bar) @foo = foo @bar = bar end end ``` My proposal mitigates the problem to two times. ``` class C def initialize(foo, bar) ^^^@foo ^^^@bar end ``` ## Patch A proof-of-concept is attached. ``` $ cat test.rb p(2 * 3 * 7) ^^^^^var p var while gets != nil ^^^^line p line end ary = [1, 2, 3, 4, 5] ary.each {|elem| elem if elem.even? } ^^^^found p found #=> 4 $ echo -e "foo\nbar" | ./miniruby test.rb 42 6 "foo\n" "bar\n" 4 ``` Notes: * The syntax allows only ASCII characters because ["East Asian width"](http://www.unicode.org/reports/tr11/) is a hell. * My patch does not implement binding a method parameter (Use case 3). * There are some known bugs. Look for them. ## Compatibility A line that suddenly starts with `^` is invalid currently. This is why I chose "downward" since upward assignments are incompatible. ``` vvvv line while gets ``` When the previous line continues, `^` is appropriately handled as an XOR binary operator. ``` x = 1 # The following is considered as: y = 2^x y = 2\ ^x p x #=> 1 p y #=> 3 ``` So, I think this proposal is 100% compatible. ## Discussion I'm unsure how should we handle this. ``` p(2 * 3 * 7) ^^^^^var ``` ---Files-------------------------------- 2021-aprilfool.patch (9.07 KB) -- https://bugs.ruby-lang.org/