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.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY 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 4D1181F4B4 for ; Thu, 8 Apr 2021 21:43:45 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 60ED2120BDD; Fri, 9 Apr 2021 06:42:40 +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 57F0E120B9F for ; Fri, 9 Apr 2021 06:42:38 +0900 (JST) Received: by filterdrecv-747b54644c-n5966 with SMTP id filterdrecv-747b54644c-n5966-14-606F7902-3C 2021-04-08 21:43:30.54358134 +0000 UTC m=+1226371.016759964 Received: from herokuapp.com (unknown) by ismtpd0193p1mdw1.sendgrid.net (SG) with ESMTP id 85Lx8O_xT_Kl_KqdvfkBsQ for ; Thu, 08 Apr 2021 21:43:30.449 +0000 (UTC) Date: Thu, 08 Apr 2021 21:43:30 +0000 (UTC) From: marcandre-ruby-core@marc-andre.ca Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79364 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17786 X-Redmine-Issue-Author: jzakiya X-Redmine-Sender: marcandre 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?6=2FIMxCQLDposcQf5wmbDAtfaKduBAO0bKyhL3BGZtMQ5q7K2TvpbN6A7JIyt9E?= =?us-ascii?Q?aOJa2mK8cE4kHv58A5GyV9+OmPouHIic9lcRtWB?= =?us-ascii?Q?8epekQPq9YBBQNXA5phGFECEXqWDtFwHBwMrfbX?= =?us-ascii?Q?MyXsOoOGyP6xap1cGCFOJlrQixj+e0aNLfdTyWH?= =?us-ascii?Q?lbuSRyEHdpUfOjm0MJra34FDtvsSfO9w9UwL7t+?= =?us-ascii?Q?JLMc1JtRO8HHvEvTw=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103318 Subject: [ruby-core:103318] [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 marcandre (Marc-Andre Lafortune). Please no. Error prone, not particularly useful, can not be nested, potentially incompatible, ... My recommendation is to use a text editor that add the `end` for you. ---------------------------------------- Feature #17786: Proposal: new "ends" keyword https://bugs.ruby-lang.org/issues/17786#change-91406 * 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/