From: chris@... Date: 2021-04-10T15:55:07+00:00 Subject: [ruby-core:103375] [Ruby master Feature#17786] Proposal: new "ends" keyword Issue #17786 has been updated by chrisseaton (Chris Seaton). > Please focus on the intent and purpose, and not semantics. But we have to decide what the semantics will be in order to specify and implement it! The point of this issue tracker is to debate semantics of proposals. > All Ruby would have to do is go down, and back up, the parsing tree. Currently Ruby is able to parse and compile in broadly two single passes. What you're proposing is pretty radically different to that and could have serious implications for implementation, performance, and compatibility. Maybe you could write a PR introducing a specification and implementing the feature to see how you envision it being done? ---------------------------------------- Feature #17786: Proposal: new "ends" keyword https://bugs.ruby-lang.org/issues/17786#change-91468 * 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. ```ruby 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. ```ruby 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 written as: ```ruby 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/ Unsubscribe: