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=-4.1 required=3.0 tests=AWL,BAYES_00, 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 388011F4B4 for ; Fri, 9 Apr 2021 02:43:36 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 14A06121138; Fri, 9 Apr 2021 11:42:33 +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 A55CF120C3A for ; Fri, 9 Apr 2021 11:42:30 +0900 (JST) Received: by filterdrecv-59db977c98-kk6fj with SMTP id filterdrecv-59db977c98-kk6fj-14-606FBF50-1B 2021-04-09 02:43:28.691330761 +0000 UTC m=+1244365.116490185 Received: from herokuapp.com (unknown) by ismtpd0187p1mdw1.sendgrid.net (SG) with ESMTP id TJDbvqWRT7aEop4UfXJ-7g for ; Fri, 09 Apr 2021 02:43:28.576 +0000 (UTC) Date: Fri, 09 Apr 2021 02:43:28 +0000 (UTC) From: mame@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79374 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17786 X-Redmine-Issue-Author: jzakiya X-Redmine-Sender: mame 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?EJh2gqwnyqXtd++xo=2FinyA1V0bXouTB4FkWnzNiKb4=2FUgrMT4cM2A36njDyI8O?= =?us-ascii?Q?tb1KX6ScYAmxoP8NZJAHzzyZyVCOIvPBLrTE71k?= =?us-ascii?Q?qHMWMo9V6yAZu0WewAlBgUaoei4JBnwr61JWjU4?= =?us-ascii?Q?+AeAcACtdfgmsv2o+403lAlcuH=2FHo4OmY35QfCq?= =?us-ascii?Q?6GwT+PTfjzDfopB4n18MwfksGzo5wsCDQ0A=3D=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103328 Subject: [ruby-core:103328] [Ruby master Feature#17786] Proposal: new "ends" keyword 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 #17786 has been updated by mame (Yusuke Endoh). Tags deleted (joke) I agree that this proposal is very unlikely to be successful, but I guess the proposer is serious, so I'm removing "joke" tag. ---------------------------------------- Feature #17786: Proposal: new "ends" keyword https://bugs.ruby-lang.org/issues/17786#change-91419 * Author: jzakiya (Jabari Zakiya) * Status: Open * Priority: Normal ---------------------------------------- I'm submitting this in the same spirit that ``endless methods`` was, to promote and produce more concise and easier to write|read code. **Proposal** This is a proposal to introduce a new keyword ``ends`` (or ``endall``) as a terminal point to resolve the end of nested ``loops|conditionals``. **Why** It's a common code occurrence to have multiple levels of loops and/or conditionals, which require separate ``end`` keywords to designate their termination points. The ``end`` statements themselves are merely for syntactic purposes. It would be a benefit to programmers, and code readers, to be able to produce|read more concise code, by reducing the ``code noise`` of these nested multiple ``end`` keywords with a shorter|cleaner syntax. Thus, I propose creating the keyword ``ends`` as a shorter|cleaner syntax to replace having to write multiple ``end`` keywords. **Example** Below is an example of real code which performs nested loops. With "standard`` format it looks like this. ``` def render(scene, image, screenWidth, screenHeight) screenHeight.times do |y| screenWidth.times do |x| color = self.traceRay(....) r, g, b = Color.toDrawingColor(color) image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b)) end end end ``` However, from the point of view of the parser, these are all legal|equivalent. ``` def render(scene, image, screenWidth, screenHeight) screenHeight.times do |y| screenWidth.times do |x| color = self.traceRay(....) r, g, b = Color.toDrawingColor(color) image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b)) end end end end end end end end end end end end ``` This proposal would allow this type of code to be writtn as: ``` def render(scene, image, screenWidth, screenHeight) screenHeight.times do |y| screenWidth.times do |x| color = self.traceRay(....) r, g, b = Color.toDrawingColor(color) image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b)) ends ``` **Pros** 1) code conciseness 2) better readability 3) no whitespace dependencies 4) no conflict with legacy code 5) attractice to people coming from Python|Nim, et al **Cons** No technical implementation restrictions I can think of. Maybe alternative name (endall)? Thanks for consideration. -- https://bugs.ruby-lang.org/