Issue #17786 has been updated by duerst (Martin D=FCrst).


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`` statem=
ents, and nothing more.

We understand your "intent". And I think it would be great if we could redu=
ce 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 exa=
ct definitions.

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

There are other languages that use indentation for program structure, such =
as Haskell. Are you saying that you `ends` proposal would include using ind=
entation levels to decide how many `end` keywords a single `ends` would sta=
nd 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 incompatibilit=
ies 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 co=
de will run on 3.0. This feature would create the same options for programm=
ers to assess using, or not.

There is a compatibility issue. Chris mentioned it in https://bugs.ruby-lan=
g.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 pro=
mote 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 condi=
tionals, which require separate ``end`` keywords to designate their
termination points. The ``end`` statements themselves are merely for syntac=
tic purposes.

It would be a benefit to programmers, and code readers, to be able to produ=
ce|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 t=
o replace having to write multiple ``end`` keywords.

#### Example
Below is an example of real code which performs nested loops. With ''standa=
rd'' format it looks like this.

```ruby
def render(scene, image, screenWidth, screenHeight)
  screenHeight.times do |y|
    screenWidth.times do |x|
      color =3D self.traceRay(....)
      r, g, b =3D 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|equivale=
nt.

```ruby
def render(scene, image, screenWidth, screenHeight)
  screenHeight.times do |y|
    screenWidth.times do |x|
      color =3D self.traceRay(....)
      r, g, b =3D 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 =3D self.traceRay(....)
      r, g, b =3D 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=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>