From: duerst@...
Date: 2021-04-11T01:40:16+00:00
Subject: [ruby-core:103383] [Ruby master Feature#17786] Proposal: new "ends"	keyword

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


jzakiya (Jabari Zakiya) wrote in #note-13:
> The examples I provided show the intent of what its use is for, which is to provide one termination point for a string of consecutive ``end`` statements, and nothing more.

We understand your "intent". And I think it would be great if we could reduce repeated `end`s in Ruby programs. But programming languages are not (or not yet) about somehow guessing a progammer's intent, they have to have exact definitions.

> Python|Nim show they can do this, using whitespace|indentation. This makes code much more concise, easier to read|write, and easier to understand. Those string of ``end``s are merely for the benefit of the parser, and not humans.

There are other languages that use indentation for program structure, such as Haskell. Are you saying that you `ends` proposal would include using indentation levels to decide how many `end` keywords a single `ends` would stand in for? If that's the case, please explain the specifics.

> Also, there are no backwards incompatibility issues because there are no issues with parsing old code, just as there are no backwards incompatibilities with ``endless methods``. If a programmer doesn't write code to use it, there is no issue going forward, or backward. Obviously, if one wants code to run on pre 3.0 systems, one doesn't use ``endless methods``, but old code will run on 3.0. This feature would create the same options for programmers to assess using, or not.

There is a compatibility issue. Chris mentioned it in https://bugs.ruby-lang.org/issues/17786#note-1.

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

* 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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>