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

[ruby-core:124845] [Ruby Feature#18035] Introduce general model/semantic for immutability.
by Eregon (Benoit Daloze) 17 Feb '26

17 Feb '26

Issue #18035 has been updated by Eregon (Benoit Daloze). @ioquatix I think `deep_freeze` would be a clear solution for that, so probably best to add your comments/support to #21665 and potentially also add it to the dev meeting agenda. ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-116498 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

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

17 Feb '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/

3 2

[ruby-core:124843] [Ruby Misc#21916] DevMeeting before RubyKaigi 2026
by ko1 (Koichi Sasada) 17 Feb '26

17 Feb '26

Issue #21916 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Misc #21916: DevMeeting before RubyKaigi 2026 https://bugs.ruby-lang.org/issues/21916 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- RubyKaigi 2026 will be at Hakodate, Japan, Apr 22th - 24th. We would like to try to hold a face-to-face dev meeting at Hakodate. (@matz will also participate!) * Date: 2026/04/21 (Tue.) 15:00-17:00 (The day before RubyKaigi) * Location: RubyKaigi venue (detailed will be announced before the meeting) ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. Please sign up on the doorkeeper page: https://rubyassociation.doorkeeper.jp/events/195298 The meeting will be held in a hackathon event. Please enjoy Ruby hacking with friends if you want before the meeting. Note: Do not forget to register RubyKaigi ticket too (see "[ruby-core:124591] Invitation to RubyKaigi 2026" from Akira). ### Program * 11:00am door open and start the Hackathon event * 3:00pm opening and self introduction * 3:30pm discuss topics * 5:00pm closing and free time (closing time is depends on topics) * 6:00pm door close ### 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 2025/04/20. I'll ask Matz which should be discussed on this meeting and reorder them. - 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/

1 0

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

17 Feb '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 12

[ruby-core:124841] [Ruby Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 16 Feb '26

16 Feb '26

Issue #18035 has been updated by ioquatix (Samuel Williams). Another example where immutability as a concept is useful - configurations that span across fibers and threads: https://github.com/ruby-i18n/i18n/issues/723 In general, it seems like `Fiber[]` for immutable values is a good idea. ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-116462 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124840] [Ruby Bug#21883] IO::Buffer can be unlocked and freed by another thread during syscall
by hanazuki (Kasumi Hanazuki) 16 Feb '26

16 Feb '26

Issue #21883 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21883: IO::Buffer can be unlocked and freed by another thread during syscall https://bugs.ruby-lang.org/issues/21883 * Author: hanazuki (Kasumi Hanazuki) * 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 ---------------------------------------- ```ruby # Assume this file is on a very slow device such as NFS. io = File.open('/mnt/slowfs/slow') buf = IO::Buffer.new(100) t1 = Thread.new do buf.locked do sleep 0.5 end buf.free end t2 = Thread.new do buf.read(io) # syscall takes 1 second # When the kernal writes to the memory, buf is already freed, thus use-after-free end t1.join t2.join ``` `io_buffer_blocking_region` skips taking a lock when the buffer is already locked, but this lock may be owned by another thread and can be unlocked during the syscall. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124825] [Ruby Bug#21880] The ultra_safe mode of pstore bundled with Ruby 4.0 is broken.
by s3fxn (s3 fxn) 16 Feb '26

16 Feb '26

Issue #21880 has been reported by s3fxn (s3 fxn). ---------------------------------------- Bug #21880: The ultra_safe mode of pstore bundled with Ruby 4.0 is broken. https://bugs.ruby-lang.org/issues/21880 * Author: s3fxn (s3 fxn) * Status: Open * ruby -v: 4.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- here is the reproduction code. $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] $ cat pstore.rb #!/usr/bin/env ruby require "bundler/inline" gemfile do source "https://rubygems.org" if ENV['DEBUG'] gem "pstore", "0.1.4" else gem "pstore" end end db = PStore.new("pstore.db") db.ultra_safe = true db.transaction do puts db["now"] = Time.now end $ ruby pstore.rb 2026-02-15 04:49:31 +0000 /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:676:in 'Ractor.make_shareable': Proc's self is not shareable: #<Proc:0x0000749f688df078 /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:673> (Ractor::IsolationError) from /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:676:in 'PStore#on_windows?' from /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:685:in 'PStore#save_data' from /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:575:in 'PStore#transaction' from pstore.rb:14:in '<main>' $ DEBUG=1 ruby pstore.rb 2026-02-15 04:49:53 +0000 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:124833] [Ruby Bug#21882] IO::Buffer#locked leaves the buffer locked when the block raises
by hanazuki (Kasumi Hanazuki) 16 Feb '26

16 Feb '26

Issue #21882 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21882: IO::Buffer#locked leaves the buffer locked when the block raises https://bugs.ruby-lang.org/issues/21882 * Author: hanazuki (Kasumi Hanazuki) * 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 ---------------------------------------- `IO::Buffer#locked` should unlock the buffer even after the block raises an exception. ```ruby buf = IO::Buffer.new(100) buf.locked { fail } rescue nil buf.locked { p :ok } # expected to print :ok, but actually raises a LockedError ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124824] [Ruby Bug#21879] SSLBypass
by sh2ll (Chmouel Taieb) 15 Feb '26

15 Feb '26

Issue #21879 has been reported by sh2ll (Chmouel Taieb). ---------------------------------------- Bug #21879: SSLBypass https://bugs.ruby-lang.org/issues/21879 * Author: sh2ll (Chmouel Taieb) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- There is not enough space for photos upload ---Files-------------------------------- Critical SSL Verification Bypass Report.pdf (87.4 KB) ScriptsPOC.pdf (49.5 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil`
by ufuk (Ufuk Kayserilioglu) 15 Feb '26

15 Feb '26

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu). ---------------------------------------- Feature #19979: Allow methods to declare that they don't accept a block via `&nil` https://bugs.ruby-lang.org/issues/19979 * Author: ufuk (Ufuk Kayserilioglu) * Status: Open * Priority: Normal ---------------------------------------- ## Abstract This feature proposes new syntax to allow methods to explicitly declare that they don't accept blocks, and makes passing of a block to such methods an error. ## Background In #15554, it was proposed to automatically detect methods that do not use the block passed to them, and to error if a block was passed to such methods. As far as I can tell, it was later on closed since #10499 solved a large part of the problem. That proposal has, as part of the dev meeting discussion, a proposal from @matz to allow methods to use `&nil` to explicitly declare that they don't accept a block. At the time, the proposal was trying to solve a bigger problem, so this sub-proposal was never considered seriously. However, notes in the proposal say: > It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) This proposal extracts that sub-proposal to make this a new language feature. ## Proposal In Ruby, it is always valid for the caller to pass a block to a method call, even if the callee is not expecting a block to be passed. This leads to subtle user errors, where the author of some code assumes a method call uses a block, but the block passed to the method call is silently ignored. The proposal is to introduce `&nil` at method declaration sites to mean "This method does not accept a block". This is symmetric to the ability to pass `&nil` at call sites to mean "I am not passing a block to this method call", which is sometimes useful when making `super` calls (since blocks are always implicitly passed). Explicitly, the proposal is to make the following behaviour be a part of Ruby: ```ruby def find(item = nil, &nil) # some implementation that doesn't call `yield` or `block_given?` end find { |i| i == 42 } # => ArgumentError: passing block to the method `find' that does not accept a block. ``` ## Implementation I assume the implementation would be a grammar change to make `&nil` valid at method declaration sites, as well as raising an `ArgumentError` for methods that are called with a block but are declared with `&nil`. ## Evaluation Since I don't have an implementation, I can't make a proper evaluation of the feature proposal. However, I would expect the language changes to be minimal with no runtime costs for methods that don't use the `&nil` syntax. ## Discussion This proposal has much smaller scope than #15554 so that the Ruby language can start giving library authors the ability to explicitly mark their methods as not accepting a block. This is fully backward compatible, since it is an opt-in behaviour and not an opt-out one. Future directions after this feature proposal could be a way to signal to the VM that any method in a file that doesn't explicitly use `yield`/`block_given?` or explicitly declared a block parameter should be treated as not accepting a block. This can be done via some kind of pragma similar to `frozen_string_literal`, or through other means. However, such future directions are beyond the scope of this proposal. ## Summary Adding the ability for methods to declare that they don't accept a block will make writing code against such methods safer and more resilient, and will prevent silently ignored behaviour that is often hard to catch or troubleshoot. -- https://bugs.ruby-lang.org/

10 25