- ruby-core - ml.ruby-lang.org

[ruby-core:124905] [Ruby Feature#21932] `MatchData#get_int`
by nobu (Nobuyoshi Nakada) 18 Mar '26

18 Mar '26

Issue #21932 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21932: `MatchData#get_int` https://bugs.ruby-lang.org/issues/21932 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- This is suggested by @akr today, `$~.get_int(1)` is equivalent to `$1.to_i` but does not create the intermediate string object. -- https://bugs.ruby-lang.org/

7 8

[ruby-core:124808] [Ruby Misc#21877] DevMeeting-2026-03-17
by mame (Yusuke Endoh) 17 Mar '26

17 Mar '26

Issue #21877 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21877: DevMeeting-2026-03-17 https://bugs.ruby-lang.org/issues/21877 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/03/17 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/03/14. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

7 7

[ruby-core:125059] [Ruby Bug#21824] performance regression in regexp matching after update to 4.0
by mackuba (Kuba Suder) 17 Mar '26

17 Mar '26

Issue #21824 has been updated by mackuba (Kuba Suder). @khasinski Looks like this was not backported to the branch from which 4.0.1/4.0.2 were packaged?… :\ ---------------------------------------- Bug #21824: performance regression in regexp matching after update to 4.0 https://bugs.ruby-lang.org/issues/21824#change-116760 * Author: mackuba (Kuba Suder) * Status: Closed * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TLDR: a change in the regexp algorithm in regcomp.c merged around October was supposed to speed up the matching, but it seems it has slowed it down more in practice. === I'm running a service written in Ruby which serves some number of Bluesky feeds. As part of this service, I have a process that connects to a websocket API (w/ EventMachine), reads from it all new posts made on the network in real time (on the order of ~100 posts per second on average lately), and passes each post through a #post_matches? method in about 20 feed objects, each of which has a number of regexps configured (most have around 20-30, but one has a few hundred, probably something like 900 regexps in total). If a given post's text (up to 300 unicode characters) matches any of the regexps of the given feed (and/or matches some additional conditions), it's added to this feed in the database. I often use a slightly older version of this project with a fixed pre-downloaded chunk of the posts stream, with ~100k random but real posts in one large binary file, as a benchmark on different versions of Ruby. So I ran it again on 4.0 after it was released a week ago, and I got this: https://bsky.app/profile/mackuba.eu/post/3mb2quhdoqs23 The numbers are the calculated speed of processing, in events per second, after going through the whole sample of 100k events and a full set of feeds. So there was a 5-6% slowdown on Ruby 4.0 vs. Ruby 3.4 (with or without YJIT), putting it below any version of Ruby since 3.0. I started profiling which specific parts of the code got slower, and I narrowed it down to regexp matching (the full loop also does e.g. decoding of data from a binary format from the file). I made a demo project reproducing this here (note, linking to a slightly earlier commit): https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/63e208de944debdc0a6…. There are 940 posts here in the sample and 17 regexps, and running 1000 loops takes 7 seconds on Ruby 3.4, but 13.5s on 4.0 (so almost 2x longer). Then, I started digging into the details to see if some specific posts or specific regexps cause the slowdown. It turned out that most of the 17 regexps, if tested alone, work about the same on 3.4 & 4.0, but two work around 4x slower: /\bslackware\b/i and /\bkde plasma\b/i. (This seems to be not only about the length of the regexp, but also specific characters, because e.g. /\blongstring\b/i does not trigger this effect.) It also seems that this only happens if the searched string contains non-ASCII characters. An updated, more minimal version of the demo is here: https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/d9e145c1e9f39fca6dd…. One regexp and one string. With a million loops, it takes 0.75s on Ruby 3.4, but 2.7s on Ruby 4.0. (No change on latest master, ruby 4.1.0dev (2026-01-05T17:18:47Z master 7e81bf5c0c), i.e. it's still much slower than on 3.4.) If the few non-ASCII characters (apostrophe, ndash, ellipsis, TM) are removed from the string, the slowdown goes away. Finally, with some help from Codex I tried to track down which specific change between 3.4 and 4.0 caused this slowdown. It turned out to be this commit: https://github.com/ruby/ruby/commit/981ee02c7c664f19b983662d618d5e6bd87d1739, authored in November 2017 (!), but merged around 31st October this year. It says it "fixes performance problem with /k/i and /s/i". I'm not familiar with these string search algorithms so I'm not able to evaluate this in detail or say how this could be fixed, but from the description I'm assuming that it improves performance in some cases of text/regexp, but apparently degrades it in some others like mine. Since in my main test of a practical scenario which matches ~100k posts against ~900 regexps, as well as the earlier demo which matches 940 posts against 17 regexps, the updated version in 4.0 is slower (5% and 47% slower, respectively), my guess is that the net result will generally be negative, i.e. that this change committed in October makes more cases slower than it makes faster. But like I said, I don't know enough about regexp algorithms to analyze this deeper, I can only report my results. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124660] [Ruby Feature#21858] `Kernel#Hash` considers `to_h` too
by ccmywish (Aoran Zeng) 17 Mar '26

17 Mar '26

Issue #21858 has been reported by ccmywish (Aoran Zeng). ---------------------------------------- Feature #21858: `Kernel#Hash` considers `to_h` too https://bugs.ruby-lang.org/issues/21858 * Author: ccmywish (Aoran Zeng) * Status: Open ---------------------------------------- 1. `Kernel#Integer` uses `to_int` first and `to_i` second 2. `Kernel#Array` uses `to_ary` first and `to_a` second 3. `Kernel#Hash` only uses `to_hash` I don't quite understand why there is a need for differential treatment here. I admit that maybe the only benefit of considering `to_h` secondly is that it enables multiple APIs to maintain consistency. -- https://bugs.ruby-lang.org/

4 11

[ruby-core:124857] [Ruby Bug#21921] Hash inconsistent ==, >=, <= behavior
by cohen (Cohen Carlisle) 17 Mar '26

17 Mar '26

Issue #21921 has been reported by cohen (Cohen Carlisle). ---------------------------------------- Bug #21921: Hash inconsistent ==, >=, <= behavior https://bugs.ruby-lang.org/issues/21921 * Author: cohen (Cohen Carlisle) * 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 ---------------------------------------- Hash seems to have very inconsistent behavior for `==`, `>=`, and `<=`. Given that below h1 == h2 is `false` and that they have the same number of keys, I would expect `<=` and `>=` to also be `false`. However, surprisingly `h1 <= h2` and `h2 >= h1` are `true`, while all other permutations are `false`. ``` h1 = {}.compare_by_identity.tap { _1["one"] = 1 } # => {"one" => 1} h2 = {"one" => 1} # => {"one" => 1} h1 == h2 # => false h2 == h1 # => false h1 >= h2 # => false h1 <= h2 # => true h2 >= h1 # => true h2 <= h1 # => false ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:125046] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by matz (Yukihiro Matsumoto) 17 Mar '26

17 Mar '26

Issue #17056 has been updated by matz (Yukihiro Matsumoto). I think it's good to add an offset: keyword argument to `Array#index` and `Array#rindex`, for consistency with `String#index` and `String#rindex`. As for `Array#find_index`, I think we should add `offset:` there as well, keeping it in sync with `Array#index`. We will leave `Enumerable#find_index` untouched, since adding an offset to a lazy enumerable feels unnatural. We have no plan to add an end index for now. Matz. ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-116745 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122847] [Ruby Feature#21520] Feature Proposal: Enumerator::Lazy#peek
by nuzair46 (Nuzair Rasheed) 17 Mar '26

17 Mar '26

Issue #21520 has been reported by nuzair46 (Nuzair Rasheed). ---------------------------------------- Feature #21520: Feature Proposal: Enumerator::Lazy#peek https://bugs.ruby-lang.org/issues/21520 * Author: nuzair46 (Nuzair Rasheed) * Status: Open ---------------------------------------- # Abstract Add a #peek method to Enumerator::Lazy that allows observing each element in a lazy enumeration pipeline without modifying or consuming the stream. # Background Ruby provides Enumerator::Lazy for efficient lazy stream processing. However, unlike languages such as Java, it lacks a clean way to inspect intermediate elements during lazy evaluation. Currently, developers must misuse .map for side effects, example: ```rb (1..).lazy.map { |x| puts x; x }.select(&:even?).first(3) ``` This is semantically incorrect and confusing, since .map implies transformation, not observation. # Proposal Introduce Enumerator::Lazy#peek, which yields each item to a block and returns the item unmodified, similar to Object#tap, but in a lazy stream: ```rb (1..).lazy .peek { |x| puts "saw: #{x}" } .select(&:even?) .first(3) ``` This would be equivalent to: ```rb lazy.map { |x| block.call(x); x } ``` but with improved semantic clarity. # Use cases • Debugging lazy enumerators without breaking the chain • Logging or instrumentation in pipelines • Educational / demo use for showing lazy evaluation step-by-step • Cleaner replacement for map { puts x; x } hacks Example: ```rb data = (1..).lazy .peek { |x| puts "got #{x}" } .select(&:even?) .first(5) ``` result: ```rb got 1 got 2 got 3 got 4 got 5 ``` And return [2, 4, 6, 8, 10] # Discussion #peek is a minimal, non-breaking addition that improves clarity and idiomatic usage of Enumerator::Lazy. It avoids abusing .map for observation and is familiar to developers from other languages. #peek is also not needed for other enumerators where .tap or .each can do the job. It mirrors Java’s .stream().peek(...) and makes Ruby’s lazy enumeration more expressive and readable. # See also • [Java Stream.peek](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Str… I would be glad to work on this and make a PR. Thank you. -- https://bugs.ruby-lang.org/

4 14

[ruby-core:124892] [Ruby Feature#21929] Add configure script options for instrumenting Rust builds
by jprokop (Jarek Prokop) 17 Mar '26

17 Mar '26

Issue #21929 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Feature #21929: Add configure script options for instrumenting Rust builds https://bugs.ruby-lang.org/issues/21929 * Author: jprokop (Jarek Prokop) * Status: Open ---------------------------------------- Ruby at this moment optionally includes Rust bits. Right now this touches mostly YJIT and ZJIT. Rust is a compiled language with various compile flags at various stages and approaches. My ask is to provide a way to instrument compilation similarly as with C at the moment so that packagers and distributions can be fully and easily compliant with their guidelines on compilation flags. Currently, for production build of Ruby, `rustc` tool is used, which is instrumented differently from `cargo` in debug builds. In my PR motivated by the described goal: https://github.com/ruby/ruby/pull/15695 I have focused on providing `rustc` with our distribution flags, during the PR it was mentioned that there are flags related to security https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 that should be present even when providing distribution flags. This is not too different from C, as there are also security flags, such as configure script enabling the arm64's BTI and PAC when possible. `rustc` of version 1.92, at the time of the PR uses the last mention of a flag. Ideally `rustc` would know `RUSTFLAGS`, but as far as I can tell, the enviroment variable only affects `cargo`. In Fedora the current guidance recommends using `%build_rustflags` https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_compiler_f… which expands to `-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn` The best result is each part of Rust in Ruby would receive the flags defined during `configure` time. In cases where complication flags should conflict, in Fedora distribution flags take precedence: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_building_w… -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125041] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 17 Mar '26

17 Mar '26

Issue #6012 has been updated by Eregon (Benoit Daloze). Right, I will make a proposal for `Ruby::SourceLocation`/`Ruby::CodeLocation` or so. I hope it can be approved quickly without taking more time. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116739 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125039] [Ruby Feature#21822] Expose Return Value in the ensure Block
by matz (Yukihiro Matsumoto) 17 Mar '26

17 Mar '26

Issue #21822 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected Thank you for the feedback. I understand the aesthetic appeal, but "cleaner" is subjective, and the existing pattern is already idiomatic Ruby with no real cognitive overhead. More importantly, "purely additive" does not mean cost-free. Every new syntax must be defined precisely, documented, and handle edge cases correctly. As nobu noted in #3, the semantics when an exception is raised are not obvious, which suggests the concept has rough edges that outweigh the cosmetic benefit. Matz. ---------------------------------------- Feature #21822: Expose Return Value in the ensure Block https://bugs.ruby-lang.org/issues/21822#change-116736 * Author: artemb (Artem Borodkin) * Status: Rejected ---------------------------------------- I'd like to propose a simple feature that allows easy access to the return value inside an ensure block. ```ruby begin # ... ensure => ret # ret is nil if an exception is raised LOGGER.debug "return value: #{ret}" end ``` -- https://bugs.ruby-lang.org/

1 0