Feature #21515: Add `&return` as sugar for `x=my_calculation; return x if x`

• Status: Open
• Assignee: -
• Target version: -

[nhorton (Noah Horton)]

Let me preface this by saying I have no marriage to the exact keyword name of &return.

Problem

It is very common to have an early return in code where you get some initial value and return it if it is non-null. i.e.

return my_calculation(input_a, input_b) if my_calculation(input_a, input_b)

That form on its own is verbose and one where you need to look at it for a moment to confirm it is the same code on either side of the if.

If my_calculation is non-trivial at all, it normally gets turned into something with a variable:

my_calc = my_calculation(input_a, input_b)
return my_calc if my_calc

That is now two lines. The worse scenario, however, is if the user did not bother doing that and my_calculation turned out to be expensive (and they did not know it).

Proposal

I propose a syntax of &return my_calculation(input_a, input_b) where it will evaluate the argument and return it as the result of the method if it is non-nil, otherwise it will continue on.

Alternatives

Do Nothing

There is no way to work around this with rolling your own methods. You can't make a returnif method or something yourself since you can't do a return in the caller's scope.

Different Name

The best other name I saw were permutations of returnif. The biggest issue I see is the similarity of the following two statements:

return if foo
returnif foo

Those are obviously very, very different statements, but are somewhat similar. However, things like this are common, and the code is still quite distinct on those, so I think it is acceptable.

Ultimately, this feels so similar to the safe navigator that using & in this context feels appropriate.

Thank you all for your consideration.

[vo.x (Vit Ondruch)]

Proposal like this always reminds me:

https://poignant.guide/book/chapter-3.html

How am I supposed to read the &return my_calculation(input_a, input_b). Reading it "and return my calculations from input_a and input_b" does not make sense to me.

[Earlopain (Earlopain _)]

I would prefer it like this:

return result if result = my_calculation(input_a, input_b)

It doesn't need new syntax and to me at least it is rather intuitive. Unfortunatly this doesn't work today because the return code doesn't see the local that was declared in the if condition. You would have to write it as a multiline if or do result = nil above it which kinda defeats the point.

[nobu (Nobuyoshi Nakada)]

Why not:

x = my_calculation(input_a, input_b) and return x

[masterleep2 (Bill Lipa)]

Also:

my_calculation(input_a, input_b)&.then{return it}

[lpogic (Łukasz Pomietło)]

The advantage of the proposed syntax is that it does not require an explicit declaration of an auxiliary variable, like here:

return result if result = my_calculation(input_a, input_b)

and here:

x = my_calculation(input_a, input_b) and return x

It also does not require creating an extra Proc like here:

my_calculation(input_a, input_b)&.then{return it}

Is there any other way to write this without the consequences I mentioned?

[jeremyevans0 (Jeremy Evans)]

lpogic (Łukasz Pomietło) wrote in #note-5:

The advantage of the proposed syntax is that it does not require an explicit declaration of an auxiliary variable, like here:

return result if result = my_calculation(input_a, input_b)

and here:

x = my_calculation(input_a, input_b) and return x

It also does not require creating an extra Proc like here:

my_calculation(input_a, input_b)&.then{return it}

Not sure why the local variable declaration would matter, as long as you don't pick one already in use. However, you are incorrect about my_calculation(input_a, input_b)&.then{return it} creating a Proc. Using a block does not automatically create a Proc (that would be very slow). Using &.then{return it} does not create a Proc:

def my_calculation(a, b)
  a == b || nil
end

def t(a, b)
  my_calculation(a, b)&.then{return it}
  proc{}
end

before = {}
after = {}

cases = [[1, 1], [1, 2]]
GC.start
GC.disable
cases.each do |a, b|
  ObjectSpace.count_objects(before)
  c = t(a, b)
  ObjectSpace.count_objects(after)
  # Procs have T_DATA internal type
  p [a, b, c, after[:T_DATA] - before[:T_DATA]]
end

Output:

[1, 1, true, 0]
[1, 2, #<Proc:0x0000011fe401f310 -:7>, 1]

[lpogic (Łukasz Pomietło)]

jeremyevans0 (Jeremy Evans) wrote in #note-6:

Not sure why the local variable declaration would matter, as long as you don't pick one already in use.

Because you have to write the name of the variable twice. And coming up with names can be tedious. Especially for trivial and repetitive patterns like this one.

jeremyevans0 (Jeremy Evans) wrote in #note-6:

However, you are incorrect about my_calculation(input_a, input_b)&.then{return it} creating a Proc. Using a block does not automatically create a Proc (that would be very slow). Using &.then{return it} does not create a Proc:

Indeed, you are right. Anyway, the "&.then" option does extra work, making it a bit slower:

require 'benchmark'

def my_calculation(a, b)
  a + b
end

def calculate_with_if
  x = my_calculation(1, 1); return x if x
end

def calculate_with_and
  x = my_calculation(1, 1) and return x
end

def calculate_with_then
  my_calculation(1, 1)&.then{ return it }
end

n = 10_000_000

Benchmark.bmbm do |x|
  x.report("x = my_calculation(1, 1); return x if x")  { n.times{ calculate_with_if } }
  x.report("x = my_calculation(1, 1) and return x") { n.times{ calculate_with_and } }
  x.report("my_calculation(1, 1)&.then{ return it }") { n.times{ calculate_with_then } }
end

                                              user     system      total        real
x = my_calculation(1, 1); return x if x   0.954000   0.000000   0.954000 (  0.947969)
x = my_calculation(1, 1) and return x     0.968000   0.000000   0.968000 (  0.970023)
my_calculation(1, 1)&.then{ return it }   2.532000   0.015000   2.547000 (  2.539123)

It's not bad. But I just wanted to know if there was a way that would, like the proposed syntax, avoid this compromise.

[tompng (tomoya ishida)]

Instead of adding new syntax to return part, how about a new keyword to reference if-predicate part?
It can be used for wider range of purposes like this:

return that if @cache[key]
puts that if my_calculation
x = that + 42 if my_calculation

I'm not sure if that is a good name, it might also be good except that it breaks existing code like this: 4.times{p it if it >= 2}.

[matheusrich (Matheus Richard)]

At least with ActiveSupport you can do:

my_calculation(input_a, input_b).try { return it }

Which still has some cost, but it is, IMO, a lot cleaner than &.then.

[nhorton (Noah Horton)]

Earlopain (Earlopain _) wrote in #note-2:

I would prefer it like this:

return result if result = my_calculation(input_a, input_b)

It doesn't need new syntax and to me at least it is rather intuitive. Unfortunatly this doesn't work today because the return code doesn't see the local that was declared in the if condition. You would have to write it as a multiline if or do result = nil above it which kinda defeats the point.

I agree that this syntax would be solid if it worked.

[nhorton (Noah Horton)]

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

Why not:

x = my_calculation(input_a, input_b) and return x

I have not seen it done this way. I will say that I started to say this did not work until I fully processed the and in this, so I am not sure on the legibility, but I think it is pretty good.

I will still assert that this is a worthwhile change to add. Early return is so common in Ruby that having a really clear syntax for this that folks can instantly understand succinct I think is worth it (for example, I think this would be more widely used than it is in procs), but I will say that the and syntax suggested here is the best "do nothing" that I see.

[nhorton (Noah Horton)]

vo.x (Vit Ondruch) wrote in #note-1:

Proposal like this always reminds me:

https://poignant.guide/book/chapter-3.html

How am I supposed to read the &return my_calculation(input_a, input_b). Reading it "and return my calculations from input_a and input_b" does not make sense to me.

How does my_var&.something read? The safe navigator is not exactly simple english - you need to know what it does. Comedically, though, it does conjure exactly @nobu (Nobuyoshi Nakada) wrote - x = blah and return x - in some sense, &return reads more directly than the normal safe navigator would.