Issue #16746 has been updated by marcandre (Marc-Andre Lafortune).


tldnr; I am against this proposal, it decreases readability, increases complexity and doesn't bring anything to the table (in that order)

I read the thread carefully and couldn't find a statement of what is the intended gain.

@matz, could you please explain what you see are the benefits of this new syntax (seriously)?

> We may find drawbacks in the future, but to find them, we need to experiment first.

I see many drawbacks already. Also, it is already possible to experiment with tools like https://github.com/ruby-next/ruby-next.

Here's a list of drawbacks to start:

1) Higher cognitive load.

Ruby is already quite complex, with many nuances. We can already define methods with `def`, `define_method`, `define_singleton_method`.

2) Requiring all text editors, IDE, parsers, linters, code highlighters to support this new syntax

3) Encouraging less readable code

With this endless method definition, if someone want to know what a method does, one has to mentally parse the name and arguments, and find the ` = ` to see where the code actually starts. My feeling is that the argument signature is not nearly as important as the actual code of the method definition.

```ruby
def: header_convert(name = nil, &converter) = header_fields_converter.add_converter(name, &converter)
#                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ all this needs to be scanned by the eye to get to the definition
```

That method definition, even if very simple, deserves it's own line start, which makes it easy to locate.

If Rubyists used this new form to write methods in two lines, with a return after the `=`, it is still harder to parse as if someone misses the `:` after the `def` the eye could be looking for an `end` statement.

```ruby
def: header_convert(name = nil, &converter) =
  header_fields_converter.add_converter(name, &converter)

# <<< hold on, is there a missing `end`? or is the indent wrong? Oh, no, it's a `def:`, not a `def`
def more_complex_method(...)
  # ....
end
```

I believe it is impossible to improve the readability of a one-line method as written currently. This new form can only make it harder to understand, not easier.


```ruby
def header_convert(name = nil, &converter)
  header_fields_converter.add_converter(name, &converter)
end

def more_complex_method(...)
  # ...
end
```

If `header_convert` ever need an extra line of code, there won't be a need to reformat the code either.

ˇČIndeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.ˇÉ

ˇ˝ Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship 

For these reason I am against this proposal and my hope is that is reverted and that we concentrate on more meaningful improvements.

----------------------------------------
Feature #16746: Endless method definition
https://bugs.ruby-lang.org/issues/16746#change-86314

* Author: mame (Yusuke Endoh)
* Status: Closed
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
Ruby syntax is full of "end"s.  I'm paranoid that the ends end Ruby.  I hope Ruby is endless.

So, I'd like to propose a new method definition syntax.

```ruby
def: value(args) = expression
```

As you see, there is no "end".

Examples.

```ruby
def: hello(name) =
  puts("Hello, #{ name }")

hello("endless Ruby") #=> Hello, endless Ruby
```

```ruby
def: inc(x) = x + 1

p inc(42) #=> 43
```

```ruby
x = Object.new

def: x.foo = "FOO"

p x.foo #=> "FOO"
```

```ruby
def: fib(x) =
  x < 2 ? x : fib(x-1) + fib(x-2)

p fib(10) #=> 55
```

Limitations.

* `def: foo x = x` is invalid; the parentheses for formal arguments are mandatory.
* `private def: foo = x` is invalid; this method definition cannot be an method argument.

A patch is attached.  No conflicts.

---Files--------------------------------
endless-method-definition.patch (2.47 KB)


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