From: duerst@...
Date: 2021-04-08T23:36:34+00:00
Subject: [ruby-core:103324] [Ruby master Feature#17786] Proposal: new "ends"	keyword

Issue #17786 has been updated by duerst (Martin D��rst).


Similar proposals have been made in the past, see e.g. #5054, #12241 (make sure to check the data on the second one).

jzakiya (Jabari Zakiya) wrote in #note-4:

> ```
> A.class_eval do
>   define_method :b do
>     c do
>       d do
>         e
>   ends
> 
>   def c
>   end
> end
> ```

>> So in your code example, starting at the beginning (outer most layer) the parser starts counting how many ``things`` (module|class|method names, loops, conditionals, etc) are currently open (haven���t been resolved as terminated). At some point, it counts the last thing that needs to be resolved. When it encounters the first ``end`` it tries to resolve it with the last (highest count) ``thing`` that���s still open. It then continues backing up the tree count, until all the unresolved ``things`` count is zero.

> So in the big picture, you don't have to care much about what the ``thing`` is, you just have to keep track of how many there are, because all you're going to first do is put the source code in equivalent standard format with expanded out ``end`` statements, which can then be processed as usual.

So is `do` a ``thing``, or not? In the above example, you treat three of the `do`s as ``things``, but not the forth one. Why? You say to count ``things`` down to zero, but why did you only count down to one? If counting down to zero, it means you are back at the top level. That means that `ends` cannot be used inside a class or module (or inside anything else, for that matter, except maybe for {} blocks, if these are not a ``thing``). 

----------------------------------------
Feature #17786: Proposal: new  "ends" keyword
https://bugs.ruby-lang.org/issues/17786#change-91411

* 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/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>