I'm strongly against this. Looking at the diff, it makes the code more confusing for little benefit. Code isn't poetry, it's meant to display clear and unambiguous meaning. Sometimes (all the time in this case), longer code is faster and easier to read.

Does pointless bikeshedding about style get us closer to 1.0? No, let's drop it.

Sometimes (all the time in this case), longer code is faster and easier to read.

Isn't this a slippery slope? You could easily say the same about implicit return values, which is I think something most people would probably say they love about Ruby...

If we can't agree on a style guide, we'll never reach 1.0.

Implicitness is great and helps writing code that is simple and pretty. But sometimes it is better to be explicit about some things. For example, return nil is equivalent to return without a value. Yet I'd rather use the former in most cases to clearly signal that this is a case where it explicitly returns nil, and return to exit from a method where return type doesn't matter/exists (this is obviously an opinionated example to illustrate there can be slight differences in semantic meanings).

In my opinion this PR adds improvements in some places but not in all and we need to look at the individual subjects to determine how it should be handled.

This PR shows examples of code that could be improved and it can be used to discuss these examples. But instead of just applying the results in code, it is essential to codify them in a style guide for reference and further applications. That's what we should focus on.

@ysbaddaden we've managed up to now perfectly fine with a hodgepodge of styles. How is that changing?

When I see an alone return in one line, there is absolutely no ambiguity about that is returns nothing, so a nil – because there is nothing after the return keyword.

For now, do we agree at least to have a formatter rule to transform return nil to return? Or if most disagree, the contrary.

We should a least have an unified style on this.

👍: I'm for return everywhere
👎: I'm for return nil everywhere

No, you use return nil when you're returning nil, and use return when you're returning void. The formatter cannot perform transformations between those two because it cannot know the return type of the function.

@j8r debating over return nil vs return is totally out of scope here. I explicitly stated that this is opinionated - as are most of these questions. I considered adding a note about not discussing this but I thought it was clear that this is just an unrelated example.

@straight-shoota this PR is about nils. As is, it will not likely be merged because it bring lots of debatable changes. I try to expose one point, debate and be agree on in order to move forward on the subject at least.

I think ensuring a consistent style backed by the (opinionated of course) formatter is important, either for newcomers or old contributors.

To be back on return vs return nil, for me they are the same and do the same. We must decide between them. Having to know when we should use one or the other depending on "void" concepts like @RX14 said is confusing. So we have randomly return or return nil.

Let's have one way to do the same thing for this once and for all - not that complicated, is it?

I don't mind return or return nil. Both do the same and we allow both. Otherwise, let's just make return nil a syntax error.

I also don't mind a few explicit nil here and there, as the rule for an implicit else branch is nil isn't that obvious (there's nothing to look at).

So my vote is 👎 for this (it makes things consistent, but not necessarily easier to read or understand).