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

[ruby-core:118784] [Ruby master Feature#20664] Add `before` and `until` options to Enumerator.produce
by knu (Akinori MUSHA) 08 Feb '26

08 Feb '26

Issue #20664 has been reported by knu (Akinori MUSHA). ---------------------------------------- Feature #20664: Add `before` and `until` options to Enumerator.produce https://bugs.ruby-lang.org/issues/20664 * Author: knu (Akinori MUSHA) * Status: Open ---------------------------------------- Enumerator.produce provides a nice way to generate an infinite sequence but is a bit awkward to define how to end a sequence. It lacks a simple and easy way to produce typical finite sequences in an intuitive syntax. This proposal attempts to solve the problem by adding these two options to the method: - `before`: when provided, it is used as a predicate to determine if an iteration should end before a generated value gets yielded. - `until`: when provided, it is used as a predicate to determine if an iteration should end until after a generated value gets yielded. Any value that responds to `to_proc` and returns a `Proc` object is accepted in these options. A typical use case for the `before` option is traversing a tree structure to iterate over the ancestors or following/preceding siblings of a node. The `until` option can be used when there is a clear definition of the "last" value to yield. ```ruby enum = Enumerator.produce(File, before: :nil?, &:superclass) enum.to_a #=> [File, IO, Object, BasicObject] enum = Enumerator.produce(3, until: :zero?, &:pred) enum_to_a #=> [3, 2, 1, 0] ``` ---Files-------------------------------- 0001-Add-before-and-until-options-to-Enumerator.produce.patch (10.7 KB) -- https://bugs.ruby-lang.org/

6 12

[ruby-core:122842] [Ruby Feature#21518] Statistical helpers to `Enumerable`
by Amitleshed (Amit Leshed) 07 Feb '26

07 Feb '26

Issue #21518 has been reported by Amitleshed (Amit Leshed). ---------------------------------------- Feature #21518: Statistical helpers to `Enumerable` https://bugs.ruby-lang.org/issues/21518 * Author: Amitleshed (Amit Leshed) * Status: Open ---------------------------------------- **Summary** I'd like to add two statistical helpers to `Enumerable`: - `Enumerable#average` (arithmetic mean) - `Enumerable#median` Both are small, well-defined operations that many Rubyists re-implement in apps and gems. Providing them in core avoids repeated, ad-hoc code and aligns with `Enumerable#sum`, which Ruby already ships. **Motivation** - These are among the most common “roll-your-own” helpers for arrays/ranges of numbers. - They are conceptually simple, universally useful beyond web/Rails. - Similar to `sum`, they’re primitives for quick data analysis, ETL scripts, CLI tooling, etc. - Including them encourages consistent semantics (what to do with empty sets, mixed numerics, etc.). ## Proposed API & Semantics ```ruby Enumerable#average -> Float or nil Enumerable#median -> Numeric or nil ``` ```ruby [1, 2, 3, 4].average # => 2.5 (1..4).average # => 2.5 [].average # => nil [1, 3, 2].median # => 2 [1, 2, 3, 10].median # => 2.5 (1..6).median # => 3.5 [].median # => nil ``` Ruby implementation ```ruby module Enumerable def average count = 0 total = 0.0 each do |x| raise TypeError, "non-numeric value for average" unless x.is_a?(Numeric) total += x count += 1 end count.zero? ? nil : total / count end def median arr = to_a return nil if arr.empty? arr.each { |x| raise TypeError, "non-numeric value for median" unless x.is_a?(Numeric) } arr.sort! mid = arr.length / 2 arr.length.odd? ? arr[mid] : (arr[mid - 1] + arr[mid]) / 2.0 end end ``` **Upon approval I'm more than willing to implement spec and code in C.** -- https://bugs.ruby-lang.org/

9 12

[ruby-core:124709] [Ruby Bug#21868] Prism doesn't use the ruby allocator
by byroot (Jean Boussier) 07 Feb '26

07 Feb '26

Issue #21868 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21868: Prism doesn't use the ruby allocator https://bugs.ruby-lang.org/issues/21868 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I discovered this while working on the internal side of [Feature #21861] (https://github.com/ruby/ruby/pull/15989) Prism doesn't use `ruby_xmalloc`, but raw `malloc`. I tried to fix it myself, but couldn't figure out the solution, so I left some FIXME comments: - https://github.com/ruby/ruby/blob/d066b9e01ccb2260fac8b2580c10e73335c7c7db/… - https://github.com/ruby/ruby/blob/d066b9e01ccb2260fac8b2580c10e73335c7c7db/… I'd appreciate if someone from the Prism team could look at it. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121982] [Ruby Bug#21323] irb fails to start with Namespace
by Eregon (Benoit Daloze) 07 Feb '26

07 Feb '26

Issue #21323 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21323: irb fails to start with Namespace https://bugs.ruby-lang.org/issues/21323 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ irb irb(main):001> 6 * 7 => 42 $ RUBY_NAMESPACE=1 irb /home/eregon/prefix/ruby-master/bin/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' zsh: exit 1 RUBY_NAMESPACE=1 irb ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:124705] [Ruby Bug#21867] enabling Ruby::Box changes puts/warn to no longer use $stdout/$stderr
by zenspider (Ryan Davis) 06 Feb '26

06 Feb '26

Issue #21867 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21867: enabling Ruby::Box changes puts/warn to no longer use $stdout/$stderr https://bugs.ruby-lang.org/issues/21867 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: 4.0.1+ * Backport: 4.0: UNKNOWN ---------------------------------------- On 4.0.1 or latest build as of 2026-02-06, given: ```ruby warn "run with RUBY_BOX=1 to repro the error" unless ENV["RUBY_BOX"] require "stringio" def capture_io captured_stdout, captured_stderr = StringIO.new, StringIO.new orig_stdout, orig_stderr = $stdout, $stderr $stdout, $stderr = captured_stdout, captured_stderr yield return captured_stdout.string, captured_stderr.string ensure $stdout = orig_stdout $stderr = orig_stderr end out, err = capture_io do puts "standard out!" # these go to STDOUT/STDERR, not $stdout/$stderr warn "standard err?" $stdout.print "standard out!" # these go to the stringio as expected $stderr.print "standard err?" end exp_out = "standard out!\nstandard out!" exp_err = "standard err?\nstandard err?" p OUT: out, EXP: exp_out unless out == exp_out p ERR: out, EXP: exp_err unless err == exp_err abort "bad" unless out == exp_out && err == exp_err p :good! ``` I get: ``` 10026 $ ./build/miniruby --disable=gems,did_you_mean -I./lib ./tool/runruby.rb --extout=build/.ext --archdir=build -- test_box.rb run with RUBY_BOX=1 to repro the error :good! ``` vs w/ box enabled: ``` 10027 $ RUBY_BOX=1 ./build/miniruby --disable=gems,did_you_mean -I./lib ./tool/runruby.rb --extout=build/.ext --archdir=build -- test_box.rb ... box warnings ... standard out! standard err? {OUT: "standard out!", EXP: "standard out!\nstandard out!"} {ERR: "standard out!", EXP: "standard err?\nstandard err?"} bad ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116028] [Ruby master Feature#20152] mkmf / extconf: Add a proper way to not compile the extension
by byroot (Jean Boussier) 06 Feb '26

06 Feb '26

Issue #20152 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20152: mkmf / extconf: Add a proper way to not compile the extension https://bugs.ruby-lang.org/issues/20152 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context There are various gems that ship with a native extension as a way to speedup part of the gem, but also ship with a pure Ruby version of these methods as a fallback. So they only want to compile the extension if the platform supports it, and if not, just fallback to the slightly slower Ruby version. Right now users rely on one of two hacks to do this. Either they create an empty Makefile, but then still depend on `make` being available, or publish platform specific packages without any extension in them. Examples: - [`bootsnap` skip compilation if not on MRI or TruffleRuby](https://github.com/Shopify/bootsnap/blob/070151f1305f23102365d… - [`erb` has an extension for MRI but then need to publish a `java` version of the gem that doesn't actually contain Java code, just to skip compilation on JRuby](https://github.com/ruby/erb/issues/52) - [`hiredis-client` skips the compilation for Windows and non-MRI rubies](https://github.com/redis-rb/redis-client/blob/1ab081c1d0e47df5d55e0… ### Feature It would be very useful to have some proper first class API to skip compiling the extension. Something like: ```ruby require "mkmf" if RUBY_ENGINE != "ruby" || RUBY_PLATFORM.match?(/mswin/) skip_compilation else # ... end ``` cc @k0kubun @headius -- https://bugs.ruby-lang.org/

10 21

[ruby-core:124694] [Ruby Feature#12906] do/end blocks work with ensure/rescue/else
by zverok (Victor Shepelev) 06 Feb '26

06 Feb '26

Issue #12906 has been updated by zverok (Victor Shepelev). > I tried finding out why this is called `ensure`/`rescue`/`else` when it only handles `ensure` and `rescue`? ```ruby begin File.read(filename) rescue ArgumentError puts "wrong arguments" rescue Errno::ENOENT puts "file does not exist" else puts "read successfully" end ``` `else` is part of `rescue` clause that invoked if no exception was raised; it is useful to do some post-body actions that doesn't affect the main flow (though affects the exception-handling return value). It is _documented_ [here](https://docs.ruby-lang.org/en/master/language/exceptions_md.html#else…. > I thought this might be something like the empty iterator pattern that is used in some frontend frameworks. I don't think this is possible to implement in Ruby without very serious effort and a significant toll to the mental model of the language. In your code example, `else` clause is part of the block's body; a block is mostly a "black box" for a method that receives it, and only can be interacted with via `block.call(args)`; invoking _some_ of the block statements conditionally is a questionable road. Though not unimaginable. ---------------------------------------- Feature #12906: do/end blocks work with ensure/rescue/else https://bugs.ruby-lang.org/issues/12906#change-116288 * Author: josh.cheek (Josh Cheek) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) * Target version: 2.5 ---------------------------------------- When you want to rescue in a block, you must do this: ~~~ruby lambda do begin raise 'err' rescue $! # => #<RuntimeError: err> end end.call ~~~ I've wished on numerous occasions that I could omit the begin/end and not need the extra wrapper: ~~~ruby lambda do raise 'err' rescue $! # => #<RuntimeError: err> end.call ~~~ This would be consistent with how classes and methods work: ~~~ruby class C raise 'err' rescue $! # => #<RuntimeError: err> end send def m raise 'err' rescue $! # => #<RuntimeError: err> end ~~~ It's not really clear to me how to submit this since it may require some discussion, but this is the diff: ~~~diff diff --git a/parse.y b/parse.y index 54ccc52..223e5d3 100644 --- a/parse.y +++ b/parse.y @@ -3757,7 +3757,7 @@ brace_body : {$<vars>$ = dyna_push();} do_body : {$<vars>$ = dyna_push();} {$<val>$ = cmdarg_stack >> 1; CMDARG_SET(0);} - opt_block_param compstmt + opt_block_param bodystmt { $$ = new_do_body($3, $4); dyna_pop($<vars>1); ~~~ I added tests for ensure to rubyspec, but there wasn't an obvious place to talk about rescue/else in this context (the spec for rescue only uses it in a begin/end block) It's probably fine as the spec for ensure does hit rescue, too, and they ultimately delegate to the same pieces. Not totally clear, though. I can do more with that if you need. ~~~diff diff --git a/language/ensure_spec.rb b/language/ensure_spec.rb index 13575fc..b14b0b5 100644 --- a/language/ensure_spec.rb +++ b/language/ensure_spec.rb @@ -124,3 +124,74 @@ describe "An ensure block inside a method" do @obj.explicit_return_in_method_with_ensure.should == :ensure end end + +describe "An ensure block inside a do block" do + before :each do + ScratchPad.record [] + end + + it "is executed when an exception is raised in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + ensure + ScratchPad << :ensure + end.should raise_error(RuntimeError) + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when an exception is raised and rescued in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :rescue, :ensure] + end + end + + it "is executed even when a symbol is thrown in it's corresponding do block" do + begin + catch(:symbol) do + lambda do + ScratchPad << :begin + throw(:symbol) + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + end + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when nothing is raised or thrown in it's corresponding do block" do + lambda do + ScratchPad << :begin + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :ensure] + end + + it "has no return value" do + lambda do + :begin + ensure + :ensure + end.call.should == :begin + end +end ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124687] [Ruby Bug#21864] Inconsistencies in type coercion error messages for integers
by herwin (Herwin W) 05 Feb '26

05 Feb '26

Issue #21864 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21864: Inconsistencies in type coercion error messages for integers https://bugs.ruby-lang.org/issues/21864 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux], but consisten since at least Ruby 3.2, haven't checked older releases * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Some context in https://github.com/ruby/spec/pull/1345, all code snippets are run using Ruby 4.0.1 on a 64bit Linux (Debian) system, unless stated otherwise. Ruby has some generic type coercion error message. For example: ```ruby File.truncate(var, 1) ``` Depending on the type of `var`, it can generate error messages like: ``` no implicit conversion of Integer into String (TypeError) no implicit conversion of false into String (TypeError) ``` In general `true`, `false` and `nil` print the string representation of the object, anything else prints the class of the object. One could argue that this is inconsistent, but it's probably better than printing `NilClass` in the error (something I've recently seen happen in Natalie and TruffleRuby, I would guess JRuby occasionally has this issue as well, but I haven't looked for it. The exact error messages are often missing in the Ruby specs). The conversion to integer is weird. ```ruby File.truncate("/dev/zero", var) ``` Anything other than `nil` gets pretty much the same output as before: ``` no implicit conversion of Symbol into Integer (TypeError) no implicit conversion of false into Integer (TypeError ``` But this is where nil has a special path: ``` no implicit conversion from nil to integer (TypeError) ``` Now it's usng "from .. to" instead of "of .. into", and `integer` is written in lower case. But, this message is not consistent either, based on the size of `off_t`, where the coercion uses either `rb_num2long` or `rb_num2ll`, which have different checks for `nil`: ```c // Taken from commit 86dba8cfaeabb3b86df921da24b3243b9ce4ab2a long rb_num2long(VALUE val) { again: if (NIL_P(val)) { rb_raise(rb_eTypeError, "no implicit conversion from nil to integer"); } LONG_LONG rb_num2ll(VALUE val) { if (NIL_P(val)) { rb_raise(rb_eTypeError, "no implicit conversion from nil"); } ``` That last one has some internal checks for other types, with more inconsistent error messages: ```c rb_raise(rb_eTypeError, "no implicit conversion from string"); rb_raise(rb_eTypeError, "no implicit conversion from boolean"); ``` That last one looks like the only error message to mention the term `boolean`. IMHO the first message type is the clearest, so I would propose to write every coercion failure in this way: ```ruby type = value.nil? || value == true || value == "false" ? value.inspect : value.class klass = "String" # Or Integer, or ... "no implicit conversion of #{type} into #{klass}" ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124689] [Ruby Feature#12906] do/end blocks work with ensure/rescue/else
by phoet 05 Feb '26

05 Feb '26

Issue #12906 has been updated by phoet (Peter Schröder). I tried finding out why this is called `ensure/rescue/else` when it only handles `ensure` and `rescue`? Stumbled open this in the Ruby version history https://rubyreferences.github.io/rubychanges/2.5.html#rescueelseensure-are-… I thought this might be something like the empty iterator pattern that is used in some frontend frameworks. ``` def print_elements elements.each do |e| puts e else puts "No Elements" end end ``` ---------------------------------------- Feature #12906: do/end blocks work with ensure/rescue/else https://bugs.ruby-lang.org/issues/12906#change-116282 * Author: josh.cheek (Josh Cheek) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) * Target version: 2.5 ---------------------------------------- When you want to rescue in a block, you must do this: ~~~ruby lambda do begin raise 'err' rescue $! # => #<RuntimeError: err> end end.call ~~~ I've wished on numerous occasions that I could omit the begin/end and not need the extra wrapper: ~~~ruby lambda do raise 'err' rescue $! # => #<RuntimeError: err> end.call ~~~ This would be consistent with how classes and methods work: ~~~ruby class C raise 'err' rescue $! # => #<RuntimeError: err> end send def m raise 'err' rescue $! # => #<RuntimeError: err> end ~~~ It's not really clear to me how to submit this since it may require some discussion, but this is the diff: ~~~diff diff --git a/parse.y b/parse.y index 54ccc52..223e5d3 100644 --- a/parse.y +++ b/parse.y @@ -3757,7 +3757,7 @@ brace_body : {$<vars>$ = dyna_push();} do_body : {$<vars>$ = dyna_push();} {$<val>$ = cmdarg_stack >> 1; CMDARG_SET(0);} - opt_block_param compstmt + opt_block_param bodystmt { $$ = new_do_body($3, $4); dyna_pop($<vars>1); ~~~ I added tests for ensure to rubyspec, but there wasn't an obvious place to talk about rescue/else in this context (the spec for rescue only uses it in a begin/end block) It's probably fine as the spec for ensure does hit rescue, too, and they ultimately delegate to the same pieces. Not totally clear, though. I can do more with that if you need. ~~~diff diff --git a/language/ensure_spec.rb b/language/ensure_spec.rb index 13575fc..b14b0b5 100644 --- a/language/ensure_spec.rb +++ b/language/ensure_spec.rb @@ -124,3 +124,74 @@ describe "An ensure block inside a method" do @obj.explicit_return_in_method_with_ensure.should == :ensure end end + +describe "An ensure block inside a do block" do + before :each do + ScratchPad.record [] + end + + it "is executed when an exception is raised in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + ensure + ScratchPad << :ensure + end.should raise_error(RuntimeError) + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when an exception is raised and rescued in it's corresponding do block" do + begin + lambda do + ScratchPad << :begin + raise "An exception occured!" + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :rescue, :ensure] + end + end + + it "is executed even when a symbol is thrown in it's corresponding do block" do + begin + catch(:symbol) do + lambda do + ScratchPad << :begin + throw(:symbol) + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + end + + ScratchPad.recorded.should == [:begin, :ensure] + end + end + + it "is executed when nothing is raised or thrown in it's corresponding do block" do + lambda do + ScratchPad << :begin + rescue + ScratchPad << :rescue + ensure + ScratchPad << :ensure + end.call + + ScratchPad.recorded.should == [:begin, :ensure] + end + + it "has no return value" do + lambda do + :begin + ensure + :ensure + end.call.should == :begin + end +end ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124664] [Ruby Bug#21859] Inconsistent behaviors in Regexp lookbehind/lookahead with capture groups
by trinistr (Alexander Bulancov) 05 Feb '26

05 Feb '26

Issue #21859 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21859: Inconsistent behaviors in Regexp lookbehind/lookahead with capture groups https://bugs.ruby-lang.org/issues/21859 * Author: trinistr (Alexander Bulancov) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- First issue: `Regexp.linear_time?` is `false` for a positive lookahead with a capture, but `true` for a positive lookbehind: ```ruby irb(main):002> Regexp.linear_time?(/(?=(a))/) => false irb(main):003> Regexp.linear_time?(/(?<=(a))/) => true ``` This should be `false` in both cases. Second issue: Capture group is allowed in a negative lookahead, but causes a `SyntaxError` in a negative lookbehind: ```ruby irb(main):001> /(?!(a))b/ => /(?!(a))b/ irb(main):002> /(?<!(a))b/ /home/alex/.local/share/mise/installs/ruby/4.0.1/lib/ruby/gems/4.0.0/gems/irb-1.16.0/exe/irb:9:in '<top (required)>': (irb):2: invalid pattern in look-behind: /(?<!(a))b/ (SyntaxError) ``` I believe such a capture group can never capture anything, so it probably should be an error in both cases. -- https://bugs.ruby-lang.org/

3 7