[#122900] [Ruby Bug#21529] Deprecate the /o modifier and warn against using it — "jpcamara (JP Camara) via ruby-core" <ruby-core@...>

Issue #21529 has been reported by jpcamara (JP Camara).

10 messages 2025/08/03

[#122925] [Ruby Feature#21533] Introduce `Time#am?` and `Time#pm?` — "matheusrich (Matheus Richard) via ruby-core" <ruby-core@...>

SXNzdWUgIzIxNTMzIGhhcyBiZWVuIHJlcG9ydGVkIGJ5IG1hdGhldXNyaWNoIChNYXRoZXVzIFJp

10 messages 2025/08/06

[#122932] [Ruby Bug#21534] ppc64le Ractor ractor_port_receive aborted (core dumped) — "jaruga (Jun Aruga) via ruby-core" <ruby-core@...>

Issue #21534 has been reported by jaruga (Jun Aruga).

12 messages 2025/08/07

[#122953] [Ruby Bug#21540] prism allows `foo && return bar` when parse.y doesn't — "Earlopain (Earlopain _) via ruby-core" <ruby-core@...>

Issue #21540 has been reported by Earlopain (Earlopain _).

12 messages 2025/08/12

[#122964] [Ruby Feature#21543] Point ArgumentError to the call site — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #21543 has been reported by mame (Yusuke Endoh).

8 messages 2025/08/14

[#122969] [Ruby Feature#21545] `#try_dig`: a dig that returns early if it cannot dig deeper — "cb341 (Daniel Bengl) via ruby-core" <ruby-core@...>

Issue #21545 has been reported by cb341 (Daniel Bengl).

10 messages 2025/08/15

[#122987] [Ruby Bug#21547] SEGV after 2083fa commit — "watson1978 (Shizuo Fujita) via ruby-core" <ruby-core@...>

Issue #21547 has been reported by watson1978 (Shizuo Fujita).

10 messages 2025/08/20

[#123042] [Ruby Feature#21550] Ractor.sharable_proc/sharable_lambda to make sharable Proc object — "ko1 (Koichi Sasada) via ruby-core" <ruby-core@...>

SXNzdWUgIzIxNTUwIGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGtvMSAoS29pY2hpIFNhc2FkYSkuDQoN

16 messages 2025/08/21

[#123122] [Ruby Feature#21556] Add true? and false? methods to NilClass, TrueClass, FalseClass, and String — "Phalado (Raphael Cordeiro) via ruby-core" <ruby-core@...>

Issue #21556 has been reported by Phalado (Raphael Cordeiro).

9 messages 2025/08/29

[#123146] [Ruby Bug#21559] Unicode normalization nfd -> nfc -> nfd is not reversible — "tompng (tomoya ishida) via ruby-core" <ruby-core@...>

Issue #21559 has been reported by tompng (tomoya ishida).

8 messages 2025/08/31

[ruby-core:122997] [Ruby Feature#20925] Allow boolean operators at beginning of line to continue previous line

From: "matz (Yukihiro Matsumoto) via ruby-core" <ruby-core@...>
Date: 2025-08-21 04:48:30 UTC
List: ruby-core #122997
Issue #20925 has been updated by matz (Yukihiro Matsumoto).


OK, now we have updates both for prism and parse.y. Go ahead.

Matz.


----------------------------------------
Feature #20925: Allow boolean operators at beginning of line to continue previous line
https://bugs.ruby-lang.org/issues/20925#change-114299

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/


In This Thread