Misc #22249: DevMeeting-2026-09-10

• Status: Open
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

Date: 2026/09/10 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/09/07. 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. 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.

[mame (Yusuke Endoh)]

• Related to Misc #14770: [META] DevelopersMeeting added

[byroot (Jean Boussier)]

• [Feature #22232] Deprecate RHASH_TBL and associated APIs (byroot)
  • I would like to deprecate RHASH_TBL, RHASH_TBL_RAW and rb_hash_bulk_insert_into_st_table.
  • It's a dangerous API because it allow bypassing write barriers
  • It restrict evolution of RHash, as we must always be able to convert a Hash into a public st_table.
  • gem-codesearch only revealed very old and low download gems.
  • All codesearch results have an equivalent rb_hash_* API, proving RHASH_TBL is useless.
• [Feature #22236] New API for adjustable JIT warmup (byroot)
  • JIT warmup can be a challenge in production.
  • After a deploy JIT warmup can cause high latency, so it may need to be tuned to avoid timeouts, queuing, etc.
  • Current tuning parameters like --yjit-call-threshold are hard to reason about, imprecise and need frequent update as the application changes.
  • I'd like YJIT, and potentially ZJIT to have an adjustable max_compile_time_ns.
  • When RubyVM::YJIT.runtime_stats[:compile_time_ns] goes over max_compile_time_ns stop compiling.
  • When max_compile_time_ns is assigned to a value higher than current compile_time_ns re-enable compilation.
  • It only need to be best effort.
  • See ticket for example usage.

[chucke (Tiago Cardoso)]

• [Feature #13677] Add hostname to "Name or service not known (SocketError)"
  • PR open in github: https://github.com/ruby/ruby/pull/16918
  • Changed message format as per suggestion in https://bugs.ruby-lang.org/issues/13677#note-12
• [Feature #21619] logger Context API
  • Putting it back here for lack of feedback last time around.
  • PR in github: https://github.com/ruby/logger/pull/132 . Mostly ready, main contentious point being whether the context store should be configurable or not.

[himura467 (Akito Shitara)]

• [Feature #22056] Zero-Copy String Constructor Backed by Arbitrary Ruby Object (himura467)
  • A C API creating a String that references memory owned by another Ruby object instead of copying it.
  • It was blocked on the RSTRING_PTR() NUL-termination invariant (https://bugs.ruby-lang.org/issues/22056#note-19); https://bugs.ruby-lang.org/issues/22056#note-20 proposes that only new opt-in APIs produce Strings that are not NUL-terminated.
  • Would like to ask whether this direction is acceptable, and whether the C API can proceed on it.

[hasumikin (hitoshi hasumi)]

• [Feature #22279] Region (Length / Range) Arguments for String Bit Operations (hasumikin)
  • Follow-up to [Feature #22118] (String bit operations, accepted): adds (offset, length) and Range overloads to bit_set / bit_clear / bit_flip / bit_count.
  • Semantics follow #22118: mutations raise IndexError on any overrun without modifying bits, bit_count clamps and returns 0 for an empty intersection, negative offset is IndexError, negative length is ArgumentError.
  • Points I'd like feedback on: (1) bit_count(offset) with a lone offset raises ArgumentError rather than meaning "to the end"; (2) an empty region for mutations still requires offset <= bit_size, mirroring "abc"[4, 0] being nil.

[shugo (Shugo Maeda)]

• [Bug #22276] alias in a module falls back to Object even in classes not inheriting from Object (shugo)
  • alias in a module binds Object's method at alias time, so it is broken in classes not inheriting from Object; this assumes Object is the root class, which is not true since 1.9.
  • I propose to check only the method existence with Object and resolve the alias at call time, like ZSUPER methods. PR: https://github.com/ruby/ruby/pull/18553
  • Is this change acceptable?

[tekknolagi (Maxwell Bernstein)]

• [Misc #22272] Propose Kevin Menard (@nirvdrum (Kevin Menard)) as a core committer (tekknolagi)
  • I am proposing we make Kevin Menard, a long-time and frequent contributor, a committer.
  • This will also help ZJIT: it would be nice if he could merge PRs.

[jhawthorn (John Hawthorn)]

• [Bug #22291] Instance variables should be forbidden on Ractor-shareable objects
  • Currently reading an ivar from a Ractor-shareable, but not frozen, object is only allowed on the main Ractor. But freezing these objects then incorrectly allows other Ractors to read the (possibly Ractor-unsafe) ivars.
  • I propose we forbid setting instance variables on shareable Ractor objects.
  • Currently, Ractor, ENV, Shareable proc will forbid setting instance variables (no change to Class/Module which have special rules)
  • Is this acceptable?

[ufuk (Ufuk Kayserilioglu)]

• [Feature #22300] Ractor.check_isolation: report Ractor isolation violations as warnings instead of raising (ufuk)
  • The proposal gives the ecosystem two things it does not have today for Ractor-safety:
    1. a burn-down list, to make a codebase Ractor-safe;
    2. a ratchet, to keep it Ractor-safe.
  • The attached patch has been used to find and burn-down Ractor-safety violations in the Rails codebase, as well as some internal Shopify codebases.
  • Can we ship a version of this in Ruby 4.1?

[jeremyevans0 (Jeremy Evans)]

• [Bug #22273] Aliasing doesn't interact well with Module#prepend (jeremyevans0)
  • Currently, you can an alias of a method in a prepended module.
  • This allows super to call into a descendant instead of an ancestor, from the perspective of the method calling super.
  • I think this should be rejected. alias/alias_method should only consider ancestor methods, not descendant methods, so they should not consider methods in prepended modules.
• [Feature #22266] Stop warning for duplicate keywords in splatted literal hashes (jeremyevans0)
  • Ruby does not generally warn for duplicate keywords in splatted hashes.
  • However, Ruby will warn if the splatted hash is a literal hash.
  • I think Ruby should be consistent and only warn for duplicate keywords in the same hash, and not for splatted hashes, even if the splatted hash is a literal hash.

[nobu (Nobuyoshi Nakada)]

• [Feature #22134] Faster rb_scan_args() for keyword args (optimization) (nobu)
  • Luke proposes :^ to avoid keyword hash duplication and rb_get_kwargs_const for non-destructive lookup.
  • I suggest RB_SCAN_ARGS_BORROW_KEYWORDS ("^") as both a format fragment and a feature detection macro.
  • I also suggest rb_lookup_kwargs / rb_extract_kwargs, retaining rb_get_kwargs as a compatibility alias; my prototype showed 1.13–1.35x speedups in successful keyword-parsing microbenchmarks.