Issue #17786 has been updated by jeremyevans0 (Jeremy Evans).


I don't think you could get reasonable and useful semantics for `ends`.  From your example, `ends` applies not just the end of the blocks, but also the end of the method.  To be consistent, it would have to apply to all containing scopes. Let's look at an example:

```ruby
class A
  def b
    c do
      d do
        e
  ends

  def c
  end
end
```

This would be a SyntaxError, since `ends` would end `class A`, and the final `end` would be unexpected.

You could have `ends` apply only to method definitions and not module/class definitions.  You then have to consider this case:

```ruby
A.class_eval do
  define_method :b do
    c do
      d do
        e
  ends

  def c
  end
end
```

Surely the only reasonable semantics would have the `ends` also close the `class_eval` block, since Ruby couldn't determine syntactically it is reopening a class.  This different behavior in different contexts would be a huge footgun.

Another consideration is this approach of using `ends` encourages the user to not care about the return value of the methods.  In general, that's a bad thing to encourage.  Methods that are called for side-effects should probably return `nil` or `self` to avoid returning an arbitrary value that callers of the method may accidentally depend on.

Additionally, supporting `ends` would make it more difficult to move code around (e.g. copy/paste), since the effect of `ends` could change if the context differs.

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

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