October 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:126847] [Ruby Feature#22379] Remove prism mismatch warning from `#syntax_tree`
by Earlopain (Earlopain _) 08 Oct '26

08 Oct '26

Issue #22379 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #22379: Remove prism mismatch warning from `#syntax_tree` https://bugs.ruby-lang.org/issues/22379 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- #21795 added `#syntax_tree` for a few objects. Currently it is implemented in a way that uses the prism gem, using node_id. Because it is theoretically possible that node_ids from the internal cruby version of prism don't match with the node_ids from the installed prism gem, a warning is emitted when the two versions don't match: ```rb def x = nil pp method(:x).syntax_tree # => syntax_tree: a prism gem other than the default gem is loaded; the result may not correspond exactly to the compiled code # => @ DefNode (location: (1,0)-(1,11)) # ... ``` That this version-mismatch happens is basically a given. The vendored version in cruby will not be updated and is totally separate from a users gemfile. If a new version of prism is released, it will eventually end up in a users lockfile. Or users don't update prism while bumping to a cruby patch version that vendored a newer version of prism. If I see a warning, I assume that I have to make some change in the code to avoid it but there is nothing realistic for me to do, except to stop using the method alltogether. The warning is verbose-only. However it's good practise to run test suites with warnings enabled to keep up on deprecations, so even there it does not fit. I would like this warning to become documentation only for the above reasons. @eregon also suggested to only warn when we can prove that the node_id doesn't match. That should be possible as well, since we have the code location from the iseq and can check if the node we found via prism lines up. However, that doesn't guarantee that the contents of the node are also the same. -- https://bugs.ruby-lang.org/

5 10

[ruby-core:126910] [Ruby Feature#22402] Drop support for Darwin on PowerPC
by hsbt (Hiroshi SHIBATA) 08 Oct '26

08 Oct '26

Issue #22402 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #22402: Drop support for Darwin on PowerPC https://bugs.ruby-lang.org/issues/22402 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- I propose to end support for Darwin on PowerPC, that is, Mac OS X on PowerPC Macs. This is not a proposal to drop PowerPC in general. IBM POWER on Linux (`powerpc64le`, tested on rubyci) and AIX are not affected. The last Mac OS X release for PowerPC Macs is 10.5, released in 2007, and no CI covers it. The code for this platform includes `coroutine/ppc`, `coroutine/ppc64` and the PowerPC branches under `__APPLE__`. A few people still maintain it (https://github.com/ruby/ruby/pull/8810, https://github.com/ruby/ruby/pull/18773) but I think it is time to stop carrying it. Because PowerPC Macs stop at 10.5, the same change also raises the minimum Mac OS X version checked by `configure` to 10.6. Macs running 10.6 or later are not affected. https://github.com/ruby/ruby/pull/19183 -- https://bugs.ruby-lang.org/

1 2

[ruby-core:119757] [Ruby master Bug#20872] Undefined RUBY_API_VERSION_* macros used in <ruby/backward/cxxanyargs.hpp>
by hanazuki (Kasumi Hanazuki) 08 Oct '26

08 Oct '26

Issue #20872 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #20872: Undefined RUBY_API_VERSION_* macros used in <ruby/backward/cxxanyargs.hpp> https://bugs.ruby-lang.org/issues/20872 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 3.4.0preview2 (2024-10-07 master 32c733f57b) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I just noticed that C++ compilers warn for undefined RUBY_API_VERSION_MAJOR/RUBY_API_VERSION_MINOR macros in `<ruby/backward/cxxanyargs.hpp>` when preprocessing `<ruby.h>`. ``` % cat test.cpp #include <ruby.h> % clang++ -Wundef -I ~/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0 -I ~/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/x86_64-linux -c test.cpp -o /dev/null In file included from test.cpp:1: In file included from /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby.h:38: In file included from /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/ruby.h:27: In file included from /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/internal/anyargs.h:83: /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/backward/cxxanyargs.hpp:540:6: warning: 'RUBY_API_VERSION_MAJOR' is not defined, evaluates to 0 [-Wundef] #if (RUBY_API_VERSION_MAJOR * 100 + RUBY_API_VERSION_MINOR) >= 301 ^ /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/backward/cxxanyargs.hpp:540:37: warning: 'RUBY_API_VERSION_MINOR' is not defined, evaluates to 0 [-Wundef] #if (RUBY_API_VERSION_MAJOR * 100 + RUBY_API_VERSION_MINOR) >= 301 ^ 2 warnings generated. ``` The offending code was introduced in commit:01825e8bffd. The accompanying code comment says a deprecation warning should be emitted for some use-cases (passing ANYARGS function pointers to `rb_define_method`-series functions) with Ruby 3.x, which looks not working as intended for the current Ruby versions. This seems effectively doing no harm but just disturbing for extension developers. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126569] [Ruby Bug#22291] Instance variables should be forbidden on Ractor-shareable objects
by jhawthorn (John Hawthorn) 08 Oct '26

08 Oct '26

Issue #22291 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22291: Instance variables should be forbidden on Ractor-shareable objects https://bugs.ruby-lang.org/issues/22291 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Usually Ractor-shareable objects are frozen, but we have a number of objects which are shareable even though they aren't frozen (and likely will have more in the future from C extensions). * Classes/Modules (ignored in this issue, they have special ivar handling) * `Ractor` * `Ractor::Port` * Isolated procs/lambdas from `Ractor.shareable_proc` * `ENV` These are set shareable without the usual checks that all referenced objects are also shareable. This causes a potential issue, because these objects could have unshareable instance variables, breaking the Ractor invariant (potentially causing race conditions and segmentation faults). Currently, we attempt to avoid this by having a check on ivars read that forbids reading these from a non-main Ractor ``` R = Ractor.new {} R.instance_variable_set(:@iv, +"mutable") Ractor.new { R.instance_variable_get(:@iv) }.value #=> Ractor::IsolationError: can not access instance variables of shareable objects from non-main Ractors ``` This is detected by checking on ivar read for objects which are shareable but **not** frozen. However this isn't sound because most of these unshareable objects can be frozen, turning the check off. ```ruby R = Ractor.new {} R.instance_variable_set(:@iv, +"mutable") R.freeze Ractor.new { R.instance_variable_get(:@iv) }.value # => no error, created Ractor got access to an object it shouldn't ``` (weird quirk: `ENV#freeze` raises, but you can `Kernel.instance_method(:freeze).bind_call(ENV)` so it's still an issue) I propose that we fix this by forbidding instance variable writes to objects which are frozen. This removes the need to check on read and maintains the Ractor invariant. ``` R = Ractor.new {} R.instance_variable_set(:@iv, 123) #=> Ractor::IsolationError: can not set instance variables of shareable Ractor objects Ractor.new { R.instance_variable_get(:@foo) # => always nil, because ivars are forbidden } ``` These objects behave essentially as though they're frozen, but only the IVs are frozen. This is an important issue to solve both for correctness, and because I want us to decide the semantics so that they can be implemented in ZJIT. Currently ZJIT won't compile ivar reads on multi-ractor mode because of this issue. (I will link a patch implementing this shortly) -- https://bugs.ruby-lang.org/

5 6

[ruby-core:126988] [Ruby Bug#22413] IO#wait_readable does not distinguish nil from an omitted timeout
by rhenium (Kazuki Yamaguchi) 07 Oct '26

07 Oct '26

Issue #22413 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22413: IO#wait_readable does not distinguish nil from an omitted timeout https://bugs.ruby-lang.org/issues/22413 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I was expecting `io.wait_readable(nil)` to wait indefinitely, but it is currently treated the same as omitting the argumen, so the value set by `IO#timeout=` is used: ```ruby IO.pipe{|r,w|r.timeout=1; r.wait_readable} # returns after 1 second, as expected IO.pipe{|r,w|r.timeout=1; r.wait_readable(nil)} # also returns after 1 second ``` Is this the intended behavior? Is `io.wait_readable(nil)` supposed to be a valid call at all, or is `nil` accepted only because of a loose argument check? The documentation for `IO#wait`, `IO#wait_readable`, and `IO#wait_writable` does not explain how the timeout parameter is handled. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126975] [Ruby Bug#22410] `IO#external_encoding` / `IO#internal_encoding` segfault on an uninitialized IO
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 07 Oct '26

07 Oct '26

Issue #22410 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22410: `IO#external_encoding` / `IO#internal_encoding` segfault on an uninitialized IO https://bugs.ruby-lang.org/issues/22410 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code: ```ruby IO.allocate.external_encoding ``` (also `IO.allocate.internal_encoding`, or any `IO`/`File` subclass whose `initialize` does not call `super`, e.g. `class A < IO; def initialize(*) = nil; end; A.new.external_encoding`; `Marshal.dump` of such an object reaches the same code via `encoding_name`.) Resulted in this output: ``` io_min.rb:1: [BUG] Segmentation fault at 0x0000000000000068 ruby 4.1.0dev (2026-10-07) +PRISM [x86_64-linux] -- Ruby level backtrace information ---------------------------------------- io_min.rb:1:in '<main>' io_min.rb:1:in 'external_encoding' -- C level backtrace information ------------------------------------------- (rb_bug_for_fatal_signal+0x3b8) error.c:1183 (sigsegv+0x97) signal.c:982 libc.so.6 (rb_io_external_encoding+0x8d) io.c:13775 (vm_call_cfunc_with_frame_+0x27b) ../vm_insnhelper.c:3906 (vm_call_method_each_type+0x24a) ../vm_insnhelper.c:4898 (vm_call_method+0x39f) (vm_exec_core+0x113bc) ../vm_insnhelper.c:6285 (rb_vm_exec+0x242) vm.c:2909 (rb_ec_exec_node+0x56) eval.c:300 (ruby_run_node) eval.c:338 ``` `rb_io_external_encoding` and `rb_io_internal_encoding` read `RFILE(rb_io_taint_check(io))->fptr` and dereference it without `rb_io_check_initialized`/`GetOpenFile`, so `fptr == NULL` crashes. Other IO methods raise `IOError (uninitialized stream)` here. Also reproduces on a plain release build (Ubuntu's ruby 3.2.3). To reproduce: ``` ruby ./min.rb ``` Commit: ``` 3296d5c99ce005e4698fb27a405e01d766ad2647 (2026-09-15); also reproduced on master 9ce0df671980d669cbab8afc48124c7453897533 (2026-10-07) ``` Build configuration: ``` ../configure --disable-install-doc CC=clang-18 cflags="-fsanitize=address -fno-omit-frame-pointer -DUSE_MN_THREADS=0" cppflags="-DRUBY_DEBUG=1" optflags="-O1" debugflags="-g" ``` Operating System: ``` Ubuntu 24.04.4 LTS (x86_64), clang 18.1.3 ``` *This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)* -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126977] [Ruby Bug#22412] Assertion Failed: vm_ep_in_heap_p_:env->ep == ep
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 07 Oct '26

07 Oct '26

Issue #22412 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22412: Assertion Failed: vm_ep_in_heap_p_:env->ep == ep https://bugs.ruby-lang.org/issues/22412 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code: ```ruby pr = proc {|a, b| }.curry.dup pr.call(1) ``` (also `lambda {|a, b| }.curry.clone[1]`, or `define_method(:m, &proc {|a, b| }.curry); m(1)` which dups the proc internally) Resulted in this output (RUBY_DEBUG build): ``` ../vm.c:281: Assertion Failed: vm_ep_in_heap_p_:env->ep == ep ruby 4.1.0dev (2026-10-07) +PRISM [x86_64-linux] -- Ruby level backtrace information ---------------------------------------- min.rb:2:in '<main>' min.rb:2:in 'proc' -- C level backtrace information ------------------------------------------- (vm_ep_in_heap_p_+0x1a2) vm.c:281 (VM_ENV_ESCAPED_P+0xae) vm.c:295 (vm_make_env_each+0x133) vm.c:1120 (vm_make_env_object+0x8) vm.c:1217 (rb_vm_make_proc_lambda) vm.c:1720 (vm_call0_body+0x100a) ../vm_eval.c:164 (rb_call0+0x4c5) ../vm_eval.c:101 (iterate_method+0x144) ../vm_eval.c:896 (rb_iterate0+0x298) ../vm_eval.c:1506 (rb_block_call_kw+0x42) ../vm_eval.c:1580 (make_curry_proc) proc.c:4525 (curry+0x118) proc.c:4545 (vm_yield_with_cfunc+0x172) ../vm_insnhelper.c:5275 ``` `rb_func_proc_dup` (proc.c) gives the copy its own ep inside the new `cfunc_proc_t`, but copies `ep[VM_ENV_DATA_INDEX_ENV]` from the source. For a curried proc that slot already holds an env object (created when `curry` called `Kernel#proc`/`lambda` on the ifunc block), whose `env->ep` points into the *source* proc's storage. The duplicate's ep and its env therefore disagree. Only the debug assertion fires in our testing; we did not observe a crash or ASan report on a non-debug build, even after dropping the source proc and running `GC.start`/`GC.compact`. (Related area: Bug #20950, whose backport note mentions a `vm_ep_in_heap_p_` VM_ASSERT failure; possibly also related to Bug #22113.) To reproduce: ``` ruby ./min.rb ``` Commit: ``` 3296d5c99ce005e4698fb27a405e01d766ad2647 (2026-09-15); also reproduced on master 9ce0df671980d669cbab8afc48124c7453897533 (2026-10-07) ``` Build configuration: ``` ../configure --disable-install-doc CC=clang-18 cflags="-fsanitize=address -fno-omit-frame-pointer -DUSE_MN_THREADS=0" cppflags="-DRUBY_DEBUG=1" optflags="-O1" debugflags="-g" ``` Operating System: ``` Ubuntu 24.04.4 LTS (x86_64), clang 18.1.3 ``` *This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)* -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126974] [Ruby Bug#22409] ASan UAF and Assertion Failed: gc_validate_pc:CFP_PC(cfp) >= iseq_encoded: PC not set when allocating, breaking tracing
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 07 Oct '26

07 Oct '26

Issue #22409 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22409: ASan UAF and Assertion Failed: gc_validate_pc:CFP_PC(cfp) >= iseq_encoded: PC not set when allocating, breaking tracing https://bugs.ruby-lang.org/issues/22409 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code: ```ruby pr = proc {|a=1,b=1,c=1,d=1,e=1,f=1,g=1,h=1,i=1,j=1| pr.call } 40.times do |k| eval((0...k).map { "v#{_1}=0;" }.join + "begin; pr.call; rescue SystemStackError => e; e.backtrace; end") end p :survived ``` Resulted in this output: ``` ../gc.c:1135: Assertion Failed: gc_validate_pc:CFP_PC(cfp) >= iseq_encoded: PC not set when allocating, breaking tracing ruby 4.1.0dev (2026-10-07) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:6555 p:-11149735210633 s:85178 e:005177 l:n b:---- r:(nil) BLOCK c:6554 p:0035 s:85165 e:005164 l:n b:---- r:(nil) BLOCK min.rb:1 c:6553 p:0035 s:85152 e:005151 l:n b:---- r:(nil) BLOCK min.rb:1 ... ``` and ASan: ``` ==ERROR: AddressSanitizer: heap-use-after-free on address 0x503000029780 READ of size 8 at 0x503000029780 thread T0 #0 succ_index_lookup iseq.c:4611:16 #1 get_insn_info_succinct_bitvector iseq.c:2479:17 #2 get_insn_info iseq.c:2487:12 #3 rb_iseq_line_no iseq.c:2562:48 #4 calc_pos vm_backtrace.c:80:31 #5 calc_lineno vm_backtrace.c:92:9 #6 location_to_str vm_backtrace.c:749:18 #7 location_to_str_dmyarg vm_backtrace.c:1115:12 #8 backtrace_collect vm_backtrace.c:1106:28 #9 backtrace_to_str_ary vm_backtrace.c:1124:9 #10 rb_backtrace_to_str_ary vm_backtrace.c:1136:9 #11 vm_call_cfunc_with_frame_ vm_insnhelper.c:3904:11 ``` *This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)* -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126976] [Ruby Bug#22411] Assertion Failed: class_call_alloc_func:rb_obj_class(obj) == rb_class_real(klass)
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 07 Oct '26

07 Oct '26

Issue #22411 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22411: Assertion Failed: class_call_alloc_func:rb_obj_class(obj) == rb_class_real(klass) https://bugs.ruby-lang.org/issues/22411 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code: ```ruby class C < File::Stat; end C.allocate ``` Resulted in this output (RUBY_DEBUG build): ``` ../object.c:2310: Assertion Failed: class_call_alloc_func:rb_obj_class(obj) == rb_class_real(klass) ruby 4.1.0dev (2026-10-07) +PRISM [x86_64-linux] -- Ruby level backtrace information ---------------------------------------- stat_min.rb:2:in '<main>' stat_min.rb:2:in 'allocate' -- C level backtrace information ------------------------------------------- (rb_assert_failure_detail+0x233) error.c:1268 (rb_assert_failure) (null):0 (RCLASS_INITIALIZED_P+0x0) object.c:2310 (class_get_alloc_func) object.c:2279 (rb_class_alloc) object.c:2270 (vm_call_cfunc_with_frame_+0x27b) ../vm_insnhelper.c:3906 (vm_call_method_each_type+0x24a) ../vm_insnhelper.c:4898 (vm_exec_core+0x113bc) ../vm_insnhelper.c:6285 (rb_vm_exec+0x242) vm.c:2909 ``` On a non-debug build there is no crash, but the behaviour is wrong (regression; v3_4_0 source still passed `klass`): ```ruby class C < File::Stat; end p C.allocate.class # ruby 3.2.3: C master: File::Stat class D < File::Stat; def initialize(*) = (@x = 1); end d = D.new("/") p d.class, d.instance_variable_get(:@x) # 3.2: D, 1 master: File::Stat, nil (D#initialize is never called) ``` `rb_stat_s_alloc(VALUE klass)` calls `stat_alloc(rb_cStat, &obj)` instead of `stat_alloc(klass, &obj)`. This appears to have been introduced by 18a036a613 ("[Feature #21205] Define File::Stat#birthtime by statx"); before it the allocator was `stat_new_0(klass, 0)`. Present in v4.0.7 and current master. To reproduce: ``` ruby ./min.rb ``` Commit: ``` 3296d5c99ce005e4698fb27a405e01d766ad2647 (2026-09-15); also reproduced on master 9ce0df671980d669cbab8afc48124c7453897533 (2026-10-07) ``` Build configuration: ``` ../configure --disable-install-doc CC=clang-18 cflags="-fsanitize=address -fno-omit-frame-pointer -DUSE_MN_THREADS=0" cppflags="-DRUBY_DEBUG=1" optflags="-O1" debugflags="-g" ``` Operating System: ``` Ubuntu 24.04.4 LTS (x86_64), clang 18.1.3 ``` *This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)* -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126883] [Ruby Feature#22392] Allow refinements to define && and ||
by shugo (Shugo Maeda) 07 Oct '26

07 Oct '26

Issue #22392 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22392: Allow refinements to define && and || https://bugs.ruby-lang.org/issues/22392 * Author: shugo (Shugo Maeda) * Status: Open * Target version: 4.1 ---------------------------------------- ## Abstract I propose to allow refinements to define `&&` and `||`, so that DSLs can build expressions such as `name == "x" && age > 20`. The right-hand side is evaluated before the method is called, so short-circuiting is not customizable. ## Motivation Query builders and similar DSLs want to capture boolean expressions written in a block: ```ruby User.where { name == "x" && age > 20 } ``` Today such DSLs have to use `&` and `|` instead, which bind tighter than `==` and `>`, so every operand needs parentheses: `(name == "x") & (age > 20)`. ## Proposal `&&` and `||` can be defined as methods in refinements: ```ruby module QueryDSL refine Condition do def &&(other) = And.new(self, other) def ||(other) = Or.new(self, other) end end def User.where(&block) = build(block.refined(QueryDSL).call) User.where { name == "x" && age > 20 } # => And(Eq(name, "x"), Gt(age, 20)) ``` Semantics of `a && b` (`a || b` is symmetric): * If the class of `a` has `&&` defined by a refinement active in the current scope, `b` is evaluated and `a.&&(b)` is the result. * Otherwise, the behavior is unchanged. With a hook, the result is always `a.&&(b)`, which never short-circuits. Details: * `&&` and `||` can be defined only in refinements. Defining them elsewhere raises NameError. A hook changes when the right-hand side is evaluated, so its effect should be limited to code that opted in by `using` or `Proc#refined`, rather than reaching every method that receives such an object. There are no default methods such as `Object#&&`, so `super` is not available in a hook. * The hooks also apply in conditions such as `if a && b`, so that `x = a && b; if x` and `if a && b` behave the same. * `and` and `or` behave the same as `&&` and `||`. * `&&=` and `||=` do not use the hooks, to keep the memoization idiom. * `def &&`, `def ||`, `:&&` and `:||` become valid syntax. ## Prior art Scala and Swift treat `&&` and `||` as ordinary methods, so DSLs such as Slick define them on their own types, and the compiler resolves them statically. C# lets a type define `&`, `|`, `true` and `false`, and expands `x && y` to `T.false(x) ? x : x & y`. C++ allows overloading `&&` globally, which is discouraged because short-circuiting is lost for every user of the type. Python, Kotlin, Rust and Julia don't allow it; their DSLs use `&` and `|` with the same precedence problem as in Ruby, and PEP 335, which proposed overloadable `and`/`or`, was rejected for the cost it added to every `and`/`or` and for its complexity. This proposal follows Scala and Swift in dispatching on the receiver, at run time since Ruby is dynamically typed, and limits the definitions to refinements so that, unlike in C++, code outside the DSL keeps short-circuiting. Code that doesn't use the hooks pays nothing, unlike in PEP 335. The right-hand side is evaluated eagerly rather than passed lazily: a hook that builds an expression needs its value in any case, so laziness would add complexity without a use. -- https://bugs.ruby-lang.org/

6 10