Misc #22107: DevMeeting-2026-07-09

• Status: Open
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

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

[shugo (Shugo Maeda)]

• [Feature #22097] Add Proc#with_refinements
  • For maintainability, I've replaced the hand-written iseq deep-copy with an in-memory IBF dump+load round-trip
  • Should it warn or raise when called with different modules for the same block?
    • I prefer a performance warning (Warning[:performance]) over an exception
  • Should we prevent calls to the original Proc?
    • In the intended use cases, only the refined Proc is called, but I would prefer not to enforce it.
  • Should the memo lookup be lock-free?
    • The current implementation uses RB_VM_LOCKING() for both lookup and store, which adds ~15 ns overhead per call in multi-Ractor mode
    • See https://github.com/shugo/ruby/pull/112 for details and benchmarks
    • It introduces IMEMO_TYPE_EXT_BIT to extend imemo_type beyond 16 types.
      This may also useful for [Bug #22019], where one proposed fix is to replace stack-allocated structs passed through ifunc with GC-managed imemo objects.
  • with_refinements applies refinements through def/class/module inside the proc body, consistent with using. Is this OK?

[hasumikin (hitoshi hasumi)]

• [Feature #22118] Introduce Basic Bit Operations into String (hasumikin)
  • Are these methods suitable as the first subset?
  • Is the lsb_first: keyword acceptable?

[koic (Koichi ITO)]

• [Feature #18915] New error class: NotImplementedYetError or scope change for NotImplementedError (koic)
  • A new exception class AbstractMethodError inheriting from ScriptError has been designed.
  • Existing code may define an AbstractMethodError inheriting from something other than ScriptError. In that case a superclass mismatch raises a TypeError.
  • Is Ruby 4.1 an acceptable timing to introduce AbstractMethodError despite the incompatibility risk?

[Eregon (Benoit Daloze)]

• [Feature #21998] Add {Method,UnboundMethod,Proc}#source_range (eregon)
  • Could matz reply there?

[shugo (Shugo Maeda)]

• [Feature #22132] Scala-like for comprehensions
  • Are then and when acceptable? (yield and if are not usable due to grammar conflicts)
  • Should a comprehension scope loop variables, or leak them like for ... do?
    • I think it should scope them. Leaking is harmful when comprehensions are recursive: the loop variables are shared across recursive calls, and an outer binding can be overwritten by an inner one before it is read.
      For example, in a parser combinator where each rule is a memoized method, expr referring to itself:

      def additive = @additive ||= for x in multitive << term("+"), y in additive then x + y end | multitive
      

      Used recursively, the leaked x from the outer additive call is overwritten by the inner additive call before x + y runs, so the result is wrong.
  • Guards desugar to filter, not a lazy withFilter as in Scala. So in the strict case, each guard builds one intermediate array; users who want fusion can add .lazy. Is filter acceptable, or should we add a with_filter-like method?
  • Should multiple iterators also be supported in the for ... do form?

[byroot (Jean Boussier)]

• [Feature #22085] String#to_f and Kernel#Float shouldn't issue out of range warnings
  • Here is another example of the warning needing to be worked around: https://github.com/ruby/json/pull/1044

[hsbt (Hiroshi SHIBATA)]

• [Feature #21951] Lazy load error extension gems to speed up boot time
  • I rewrite to make autoload with C instead of gem_prelude.rb.
    • Process.warmup load error extensions eagerly now.
  • How about this proposal?

[nobu (Nobuyoshi Nakada)]

• [Feature #22135] Remove obsolete ObjectSpace#_id2ref
  • It has been marked deprecated since 4.0, but discouraged for years.
  • The tests are green including the bundled gems and benchmark tests.

[byroot (Jean Boussier)]

• [Feature #22136] sprintf shouldn't raise ArgumentError when $DEBUG is set (byroot)
  • It's the only method I know of with such behavior.
  • I think it's counter productive, if I run some code with $DEBUG = true I expect its behavior not to change (aside from priting debug information).
• [Feature #22137] Change Symbol#to_s to return frozen strings (byroot)
  • It has been returning a "chilled string" for two versions now.
  • Very large codebases have adopted Symbol.alias_method(:to_s, :name) with nice allocation reduction and no compatibility issues.
  • I think we should return a frozen string in 4.1.
  • If we're really worried, then at least emit a non-verbose warning.

[ioquatix (Samuel Williams)]

• [Feature #22138] Add RB_NOGVL_PENDING_INTERRUPT_FAIL flag for rb_nogvl.
  • Additive change to protect against race condition. Is it acceptable?
• [Bug #22133] Ruby's default SIGINT handling ignores Thread.handle_interrupt masking.
  • Can we fix it?
• [Feature #21704] Expose rb_process_status_for to C extensions.
  • Is the new public function name acceptable to @akr (Akira Tanaka)?
  • Can we merge it?

[hsbt (Hiroshi SHIBATA)]

• [Misc #22180] Provide official Windows (mswin) binary packages and a version manager (hsbt)
  • All three components (relocatable zip, build automation, and a PEP 773-style version manager) are implemented and working. I'd like to discuss the three decisions in the ticket:
    • make these official artifacts hosted on ruby-lang.org
    • sign them with a project identity like Ruby association
    • host rbmanager repo under the ruby organization