Feature #20925: Allow boolean operators at beginning of line to continue previous line

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

[Dan0042 (Daniel DeLorme)]

I would like for this to become accepted syntax:

condition1
|| condition2

condition1
&& condition2

condition1
or condition2

condition1
and condition2

This is similar to how method chaining on the second line was added in Ruby 1.9

expr
.method

And it has the same advantage: when you have a multi-line expression, instead of hunting for the dot or boolean operator at the end of line1, it's right there at the beginning of line2, making the structure very obvious and readable. Please contrast:

request.secret_key_base.present? &&
  request.encrypted_signed_cookie_salt.present? &&
  request.encrypted_cookie_salt.present? &&
  request.use_authenticated_cookie_encryption

request.secret_key_base.present?
  && request.encrypted_signed_cookie_salt.present?
  && request.encrypted_cookie_salt.present?
  && request.use_authenticated_cookie_encryption

The first expression must rely on indentation to communicate the multi-line nature of the condition, and even then it's not as immediately obvious as the second expression, where we can see easily and immediately that this is a multi-line && condition.

This syntax is also similar to how a trailing comma is allowed in arrays and hashes (and method calls since Ruby 1.9), with the same advantage. It makes for a cleaner diff when you add an element to the array/hash/conditional. Taking the previous example, imagine we are adding the condition && request.use_authenticated_cookie_encryption. Now contrast the diff between the two styles:

  request.secret_key_base.present? &&
    request.encrypted_signed_cookie_salt.present? &&
-   request.encrypted_cookie_salt.present?
+   request.encrypted_cookie_salt.present? &&
+   request.use_authenticated_cookie_encryption

  request.secret_key_base.present?
    && request.encrypted_signed_cookie_salt.present?
    && request.encrypted_cookie_salt.present?
+   && request.use_authenticated_cookie_encryption

Based on the above I would say this syntax is natural and consistent with existing Ruby syntactical elements, and would greatly improve code readability.

[Dan0042 (Daniel DeLorme)]

• Description updated (diff)

[martinemde (Martin Emde)]

The difference seems nice when you consider code like:

  if request.secret_key_base.present?
    && request.encrypted_signed_cookie_salt.present?
    && request.encrypted_cookie_salt.present?
    request.encrypted_cookie
  end

which is much easier to read than

  if request.secret_key_base.present? &&
    request.encrypted_signed_cookie_salt.present? &&
    request.encrypted_cookie_salt.present?
    request.encrypted_cookie
  end

I admit that neither of these looks great, maybe the body should be indented further, but code like this exists nonetheless. At least the first is more clear about where we've switched from condition to body.

Just because it looks interesting, here it is with and:

  if request.secret_key_base.present?
    and request.encrypted_signed_cookie_salt.present?
    and request.encrypted_cookie_salt.present?
    request.encrypted_cookie
  end

[mame (Yusuke Endoh)]

As a developer involved in the implementation of Ruby grammar, I am not a fan in this extension, but as a Ruby programmer, I understand you want to write that.

I might want to write it with the following indentation anyway.

if request.secret_key_base.present?
&& request.encrypted_signed_cookie_salt.present?
&& request.encrypted_cookie_salt.present?
  request.encrypted_cookie
end

[lpogic (Łukasz Pomietło)]

+1. Regarding indentation, I once read that a multi-line "if" condition looks better with "then":

if request.secret_key_base.present?
  && request.encrypted_signed_cookie_salt.present?
  && request.encrypted_cookie_salt.present?
then
  request.encrypted_cookie
end

[matz (Yukihiro Matsumoto)]

+1. Although it might take time to implement since we have duplicated parser implementations at the moment.

Matz.