[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窶冲 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窶冱 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>