Misc #22107: DevMeeting-2026-07-09

• Status: Closed
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

Date: 2026/07/09 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2026/DevMeeting-2026-07-09.md

• 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?
    • https://github.com/shugo/ruby/pull/126
      • do form follows for ... then semantics: loop variables do not leak, and break is a syntax error.

[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

[jhawthorn (John Hawthorn)]

• [Feature #20163] Introduce #bit_count method on Integer (jhawthorn)
  • matz asked for real-world use cases. I have use case in https://bugs.ruby-lang.org/issues/20163#note-27 (a HAMT) and many uses from existing gems (IP addr CIDR notation, hamming distance, parity, more)
  • String#bit_count (#22082 / #22118) doesn't cover this case: the bitmap always fits in a fixnum, and String would require extra allocations per operation, and does not have an efficient operation for doing creating mask from (1 << x) - 1.
  • Integer#bit_count fits well alongside Integer's existing bit methods: bit_length, Integer#[], #allbits?/#anybits?, and the bitwise operators.)
  • Implementation at https://github.com/ruby/ruby/pull/17696
  • Can this be accepted?

[rhenium (Kazuki Yamaguchi)]

• [Feature #22102] C API to obtain a C string from a Ruby String (rhe)
  • The existing StringValueCStr() is sometimes awkward to use. It would be nice to provide a simpler alternative as part of the public C API.
  • Can we add one? Is the name rb_str_cstr() acceptable?

[nobu (Nobuyoshi Nakada)]

• [Feature #22185] Add alignment directives to Array#pack and String#unpack
  • x! and @! for alignment.

[himura467 (Akito Shitara)]

• [Feature #22186] Increase the embeddable size limit for substrings created by str_subseq() (himura467)
  • str_subseq() embeds a sharable middle substring only when it fits in the smallest RString slot (about 23 bytes), even though VWA supports embedded strings up to 1024 bytes. Sizing the allocation to the actual substring length via STR_EMBEDDABLE_P() / str_alloc_embed() improves fluentd by roughly 12% on ruby-bench.
  • The fluentd improvement observed in #19315#note-52 seems to be attributable to this change (it was included in that branch), not to SHARABLE_MIDDLE_SUBSTRING itself. This fix is self-contained, does not touch the RSTRING_PTR() null-termination contract, and seems worth landing independently of #19315.
  • Is this approach acceptable? Draft PR: https://github.com/ruby/ruby/pull/17723

[mame (Yusuke Endoh)]

• Description updated (diff)
• Status changed from Open to Closed