Misc #21956: DevMeeting-2026-05-13

• Status: Open
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

Date: 2026/05/13 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/05/10. 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

[mame (Yusuke Endoh)]

Note: This is the ticket for the meeting scheduled after the dev meeting co-located with RubyKaigi (2026-04-21). Until then, please list agenda items on https://bugs.ruby-lang.org/issues/21916.

[jhawthorn (John Hawthorn)]

• [Feature #21981] Remove CREF rewriting for methods on cloned classes/modules
  • Current behaviour is inconsistent with all other constant references being lexically scoped (inheritance, mixins, define_method). Only Class#{dup,clone} has weird dynamic behaviour.
  • I think it's rarely used, however it's a breaking change.

[jeremyevans0 (Jeremy Evans)]

• [Bug #22058] {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope (jeremyevans0)
  • I found semantic issues with #super_method for refined methods.
  • For the current class, it uses refinements activated at the time the Method/InstanceMethod was created.
  • For ancestors, it uses refinements activated in the scope calling #super_method.
  • Can we define the expected semantics for #super_method for refined methods?
  • shugo: The current behaviour of super seems to have a bug; if it's fixed, super_method need not to search refinements.

[himura467 (Akito Shitara)]

• [Feature #22056] Add zero-copy String constructor backed by an arbitrary Ruby object
  • Propose adding rb_enc_str_new_external (and variants, names tentative): creates a String referencing existing memory without copying, with the GC keeping an arbitrary parent object alive
  • To fully satisfy the use case described in #22056, this proposal alone is insufficient. Two additional concerns raised in that ticket also need to be addressed:
    1. Null-termination requirement (https://bugs.ruby-lang.org/issues/22056#note-11): The proposed API requires callers to guarantee that buf[len + enc.termlen] is accessible and zero-filled.
    2. RSTRING_PTR null-termination invariant (https://bugs.ruby-lang.org/issues/22056#note-12): The new API risks violating the existing guarantee that RSTRING_PTR() always returns a null-terminated string, which existing C extensions silently rely on.
  • Should these two concerns be resolved before evaluating the merits of this proposal, or is it acceptable to discuss all three in parallel?

[nobu (Nobuyoshi Nakada)]

• [Feature #22060] Improve Pathname by migrating internal methods to pathname.c
  • The performance of related methods becomes 2..4 times faster.
  • GH-16907
  • Currently Pathname("a:.").absolute? returns true on Windows.
    It feels questionable.

[chucke (Tiago Cardoso)]

• [Feature #13677]: Add more details to error "Name or service not known (SocketError)"
  • Proposal PR adding the host into the error message
    • before: "getaddrinfo: Name or service not known (SocketError)"
    • after: "getaddrinfo 'invalid.host.com': Name or service not known (SocketError)"
• [Feature #21619]: logger: Context API
  • discussed in the dev meeting 5 months ago
  • no feedback from sonots nor tagomoris, asking for feedback again.