Feature #16746: Endless method definition

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -

[mame (Yusuke Endoh)]

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.

def: value(args) = expression

As you see, there is no "end".

Examples.

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

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

def: inc(x) = x + 1

p inc(42) #=> 43

x = Object.new

def: x.foo = "FOO"

p x.foo #=> "FOO"

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.

[shevegen (Robert A. Heiler)]

I'm paranoid that the ends end Ruby. I hope Ruby is endless.

With so many cancellations of events this year, we may not want to
want to jinx ruby too much for the 3.0 release this year because
then 3.0 itself may become the endless version! (Or we could skip
it, like PHP skipped a version ... I was briefly tempted to propose
this on this special day today, but I really don't want to jinx
it. I do, however had, remember matz joking last year about unforeseen
events ... now I hope I just did not jinx it!)

[shyouhei (Shyouhei Urabe)]

• Related to Feature #5054: Compress a sequence of ends added

[shyouhei (Shyouhei Urabe)]

• Related to Feature #5065: Allow "}" as an alternative to "end" added

[shyouhei (Shyouhei Urabe)]

• Related to Feature #12241: super end added

[mame (Yusuke Endoh)]

• File deleted (endless-method-definition.patch)

[mame (Yusuke Endoh)]

• File endless-method-definition.patch endless-method-definition.patch added

[matz (Yukihiro Matsumoto)]

• Tags deleted (joke)

I totally agree with the idea seriously, (far better than #5054, #5065 and #12241) but don't like the syntax. First I thought

def foo(a) = expression

But it is a conflicting syntax.

Matz

[mame (Yusuke Endoh)]

• Assignee set to nobu (Nobuyoshi Nakada)
• Status changed from Open to Assigned

Okay seriously. You should have written many "simple" method definitions that have only one expression:

# three-line style
def value
  @val
end

# one-line style
def value; @val; end

Surprisingly, according to the following rough estimate of ruby/ruby code base, this kind of simple method definitions account for 24% of the entire method definitions.

# three-line style: 8570
p Dir.glob("**/*.rb").map {|f| File.binread(f).scan(/^(\s*)def.*\n.*\n\1end$/).size }.sum

# one-line style: 949
p Dir.glob("**/*.rb").map {|f| File.binread(f).scan(/^\s*def.*;[^;]*;\s*end$/).size }.sum

# all method definitions: 39502
p Dir.glob("**/*.rb").map {|f| File.binread(f).scan(/\bdef\b/).size }.sum

# propotion = (8570 + 949) / 39502 = 24%

I agree that def foo(a) = expression is best, but I cannot implement it. Pass it to @nobu (Nobuyoshi Nakada) .

[ka8725 (Andrey Koleshko)]

matz (Yukihiro Matsumoto) wrote in #note-7:

I totally agree with the idea seriously, (far better than #5054, #5065 and #12241) but don't like the syntax. First I thought

def foo(a) = expression

But it is a conflicting syntax.

Matz

How about this:

def foo(a):
  expression

[ruurd (Ruurd Pels)]

shevegen (Robert A. Heiler) wrote in #note-1:

I'm paranoid that the ends end Ruby. I hope Ruby is endless.

Like - basically - a snake biting its own tail amirite ;-)

[nobu (Nobuyoshi Nakada)]

https://github.com/ruby/ruby/pull/2996

[ioquatix (Samuel Williams)]

Have you considered adopting Python's whitespace sensitive indentation?

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

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

[mame (Yusuke Endoh)]

@nobu (Nobuyoshi Nakada) implemented def foo(arg) = expression in one night. Also, it allows private def: foo = 42. Perfect.

https://github.com/ruby/ruby/pull/2996

@matz (Yukihiro Matsumoto) We are ready to perform the experiment.

[retro (Josef Šimánek)]

To be honest, I'm a little confused if this is serious proposal now, since it probably started as a joke and got some attention already at GitHub pull request (https://github.com/ruby/ruby/pull/2996) with mixed attitude.

Anyway for one-line method definitions I like part of https://bugs.ruby-lang.org/issues/5065 (originally at https://bugs.ruby-lang.org/issues/729, that was rejected because of invalid reason for the change request AFAIK). It looks "nature" to me since similar syntax is already available for blocks and often is used for one-liners. Ideally scope this syntax only for one-liners.

# original
def value; @val; end

# proposed - is that conflicting one?
def value { @val }

Alternatively, since the only use-case I have found in this issue is getter having different method and instance variable names, what about to support this out of attr_reader (and all attr_* friends)?

# few ideas
attr_reader :value, for: :val # reads as -> attribute reader "value" for instance variable "val", probably impossible for multiple definitions on one line
attr_reader value: :val # this would support multiple definitions on one line

[osyo (manga osyo)]

Using the assignment operator like def value = expects the following behavior.

value = 42
# Refer to variables outside scope
def hoge = value
hoge # => 42

However, currently it is error: undefined local variable or method.
In the Endless method definition, the scope seems ambiguous, so I need to discuss whether to capture variables.

[matz (Yukihiro Matsumoto)]

I'd like to experiment with this new syntax. We may find drawbacks in the future, but to find them, we need to experiment first.

Matz.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed

Applied in changeset git|e8f53692ca7d65c92bde6d5bc6a1aea492915d9f.

---

Endless method definition [Feature #16746]

[retro (Josef Šimánek)]

I'd like to experiment with this new syntax. We may find drawbacks in the future, but to find them, we need to experiment first.

If this was merged as an experiment, shouldn't it raise warning on usage (same as pattern matching does)?

[nobu (Nobuyoshi Nakada)]

It is not easy to control parsing time warnings, and bothers tests.

[Eregon (Benoit Daloze)]

nobu (Nobuyoshi Nakada) wrote in #note-19:

It is not easy to control parsing time warnings, and bothers tests.

The exact same applies to pattern matching and yet we added a warning there.
Testing/suppressing the warning is an eval away.

I think it's important for new experimental syntax to warn about it, especially when the right semantics are unclear.

My opinion is it should not capture, def/class/module never captured outside scopes and that shouldn't change.

[Eregon (Benoit Daloze)]

Is it intended to allow multi-line definitions in this style?
I think we should not, and only single-line expressions should be allowed.

I think that's not the original purpose of this ticket and rather an incorrect usage of this new syntax,
e.g., https://twitter.com/devoncestes/status/1256222228431228933

[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 (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.

[Eregon (Benoit Daloze)]

Noteworthy is the current syntax in trunk is def name(*args) = expr (and not def: name), so there is no visual cue that this is a endless method definition except the = which comes very late.
I agree with @marcandre (Marc-Andre Lafortune), I think it makes code just less readable and harder to maintain.

[marcandre (Marc-Andre Lafortune)]

Eregon (Benoit Daloze) wrote in #note-23:

Noteworthy is the current syntax in trunk is def name(*args) = expr (and not def: name), so there is no visual cue that this is a endless method definition except the = which comes very late.

Oh, my mistake. That syntax makes it even less readable! There are potentially = already in the method definition...

I'm even more against it 😅

I edited my post.

[zverok (Victor Shepelev)]

To add an "opinion perspective"... I, for one, even if not fascinated but at least intrigued by new syntax.

My reasoning is as follows:

• The most precious Ruby's quality for me is "expressiveness at the level of the single 'phrase' (expression)", and it is not "code golf"-expressiveness, but rather structuring language's consistency around the idea of building phrases with all related senses packed, while staying lucid about the intention (I believe that, as our "TIMTOWTDI" is opposite to Python's "there should be one obvious way...", this quality is also opposite to Pythons "sparse is better than dense")
• (I am fully aware that nowadays I am in a minority with this viewpoint: whenever the similar discussions are raised, I see a huge difference between "it can be stated in one phrase" vs "it can not", while most of my correspondents find it negligible)
• I believe that the difference of "how you write it when there is one statement" vs "...more than one statement" is intentional, and fruitful: "just add one more line to 10-line method" typically small addition, but "just add one more line to 1-line method" frequently makes one think: may be that's not what you really need to do, maybe data flow becomes unclear? One existing example:

collection.map { |x| do_something_with(x) } # one line! cool!
# ...what if I want to calculate several other values on the way? I NEED to restructure it:
collection.map do |x|
  log_processing(x)
  total += x
  do_something_with(x)
end
# ...which MIGHT imply that "I am doing something wrong", and maybe what would clearer express intent
# is separating calculation of total, and move `log_processing` inside `do_something`

• So, it was actually always felt for me as "a bit too wordy" for trivial/short methods to write it as

def some_method(foo)
  foo.bar(baz).then { |result| result + 3 }
end

• ...alongside with "nicer formatting" of empty lines between methods, and probably requirement to document every method, and whatnot, it means that extraction of trivial utility method feels like "making MORE code than necessary", so I'd really try how it would feel with

def just_utility(foo)= foo.bar(baz).then { |result| result + 3 }
def other_utility(foo)= "<#{self}(#{foo})>"
def third_utility(foo)= log.print(nicely_formatted(foo))

• ...and I believe that "what if you need to add second statement, you will reformat the code completely?" is a good thing, not bad: you'll think twice before adding to "simple utility one-statement" method something that really, actually, maybe not belongs there.

[mame (Yusuke Endoh)]

In the previous dev-meeting, matz said that it should be prohibited to define setter method with endless definition.

# prohibited
def foo=(x) = @x = x

There are two reasons:

1. This code is very confusing and it is not supposed that a destructive operation is defined in this style.
2. We want to allow def foo=42 as def foo() = 42 in future. It is difficult to implement it in short term, though. If def foo=(x) = @x = x is allowed once, it will become more difficult.

I will create a PR soon.

[mame (Yusuke Endoh)]

https://github.com/ruby/ruby/pull/3479

[pankajdoharey (Pankaj Doharey)]

Why do we even need a def . ? Why not just do it like Haskell?

triple(x) = 3*x

Since this is an assignment if triple hasn't already been assigned it should create a function otherwise it should pose a syntax error. Function redefinition error or something.

or Perhaps a let keyword ?

let double x = x * 2 

[etienne (Étienne Barrié)]

I haven't seen it mentioned in the comments so I just wanted to point out that the regular method-definition syntax doesn't require semicolons, and is very close to this experiment, given the parentheses are mandatory:

def fib(x) x < 2 ? x : fib(x-1) + fib(x-2) end

# one-line style
def value() @value end
# one-line style 3.0
def value() = @value

# one-line style setter
def value=(value) @value = value end
# not supported in 3.0
def value=(value) = @value = value

It doesn't remove the end which is the purpose of this feature sorry, but I like it because it keeps the consistency of having end, while not using more punctuation like ; or =.

Edit: Also when we use endless methods, we need parentheses for calls made in the method, whereas the regular syntax does not

# one-line style
def value() process @value end
# endless method needs parentheses
def value() = process(@value)