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 (Yukihiro Matsumoto), 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.

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 # ^ ^^^ the first `=` needs to be ignored, one has to grep for ") ="

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 someone has to get to the end of the line to locate that = . After a def the eye could be looking for an end statement.

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, the line ended with `=` 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.

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.