Misc #21839: DevMeeting-2026-02-12

• Status: Closed
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

Date: 2026/02/12 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2026/DevMeeting-2026-02-12.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/02/09. 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

[k0kubun (Takashi Kokubun)]

• [Feature #19107] Allow trailing comma in method signature (k0kubun)
  • We provided use cases in response to Matz's question, but no progress for 3 years. Can we clarify why we're not adding this?

[byroot (Jean Boussier)]

• [Feature #21800] New API to efficiently scan directories efficiently (byroot)

  • It's common for development tools to need to recursively scan the file system, but it's slower than it should be in Ruby because the API impose N+1 stat syscalls.
  • This would benefit many popular gems such as Zeitwerk, rubocop, etc.
  • Previous discussion had concern about changing the behavior of Dir.each_child and other existing methods.
  • I propose:
    *Dir.scan(path) { |entry_name, entry_type| }
    *Dir.scan(path) # => [[entry_name, entry_type], ...]
  • The type is just a symbol, similar to File::Stat#ftype
  • In case of DT_UNKNOWN, Ruby issue a lstat to obtain the real type (important for portability).

• [Feature #21788] Promote Thread::Monitor to a core class (byroot)

  • Previous discussion ended on the discussion of whether a recursive Mutex would be enough
    • Yes it would, but that's what Monitor is used for in a ton of code, I don't think it's worth causing churn here.
  • Monitor is about as useful as Mutex and yet one is a core class and the other is a "stdlib" extension.
  • Bringing it into core allow to make is about as fast as mutex, while it is currently ~20% slower.
  • I don't personally think MonitorMixin should be made core though. It can remain in monitor.rb.

[Eregon (Benoit Daloze)]

• [Feature #21863] Add RBASIC_FLAGS() and RBASIC_SET_FLAGS() (eregon)
  • Sounds OK to add? (I can make a PR, it's trivial)
  • If not, what alternative? Deprecate RBasic->flags?

[Eregon (Benoit Daloze)]

(was: [Bug #21864] Inconsistencies in type coercion error messages for integers (eregon)

• Fix already merged in https://github.com/ruby/ruby/pull/16078, no need to discuss.
• Inconsistent exception messages on the platform like no implicit conversion from nil to integer vs no implicit conversion from nil seem a clear bug/undesirable.
• How about using consistent messages for coercion errors, based on what convert_type_with_id uses?
  )

[hsbt (Hiroshi SHIBATA)]

• [Bug #21855] Bundle win32-registry or implement it without fiddle (hsbt)
  • Is it okay to extract that at Ruby 4.1 without warning cycle?
• [Feature #21835] Unbundle bunled gems like net-ftp (hsbt)
  • How about this?

[Earlopain (Earlopain _)]

• [Misc #21630] Suggest @Earlopain (Earlopain _) for core contributor (earlopain)
  • Could this be reconsidered? Recently I've made changes/wanted to make changes that require small updates in ruby/ruby
  • • https://github.com/ruby/ruby/pull/15914
  • • https://github.com/ruby/ruby/pull/15999
  • • https://github.com/ruby/ruby/pull/16052
  • • https://github.com/ruby/ruby/pull/16085
  • I have to wait on others to fix CI/help me make the changes I want to do in prism
  • Sometimes prism CI doesn't tell me that a change will break ruby CI (we run test-all only)
  • I would especially like to unbreak CI when I accidentally break it
  • It would also allow me to collaborate with parse.y maintainers in the same PR like https://github.com/ruby/ruby/pull/15498 (I think)

[jeremyevans0 (Jeremy Evans)]

• [Feature #21871] Add Module#undef_const (jeremyevans0)
  • I'd like to add this method, which offers for constants the same behavior that undef_method offers for methods.
  • This allows hiding specific constants inside a namespace, to allow for encouraging safer coding patterns in some cases.
  • My expected use case for this is to assist in avoiding IDOR (insecure direct object reference) vulnerabilities.
  • I've implemented support for this in a pull request.
  • Is the feature itself OK?
  • If so, is the implementation in the pull request OK?

[nobu (Nobuyoshi Nakada)]

• [Misc #21872] -S with directory separator
  • Its origin Perl’s -S doesn't search the script with directory separator from $PATH.
  • sh seems similar to Perl.
  • Is this behavior intentional?

[tenderlovemaking (Aaron Patterson)]

• [Feature #21785] Add LEB128 pack / unpack
  • Are we OK to merge now? I think yes, but want to check
• [Feature #21796] Add pack directive to return offset ^
  • This would be useful with LEB128, as well as other directives that @nobu (Nobuyoshi Nakada) mentions in the ticket

[byroot (Jean Boussier)]

• [Feature #21861] C API: expose ruby_xfree_sized, ruby_xrealloc_sized, etc (byroot)
  • C23 added void free_sized(void *ptr, size_t old_size).
  • It has both speed and correctness benefits.
  • Several common allocators already support it, including latest glibc and the very popular jemalloc.
  • Maps well with ruby_sized_xfree used internally to provide the freed size to GC statistics.
  • I'd like to expose ruby_xfree_sized and ruby_xrealloc_sized to C extensions so they can make use of it too.
  • I'd also like to expose RB_FREE_SIZED, RB_FREE_SIZED_N and RB_REALLOC_SIZED_N macros for convenience.

[ioquatix (Samuel Williams)]

• [Feature #15330] Introduce autoload_relative.
  • autoload is used widely and autoload_relative is more efficient (no load path search).
  • Can we introduce autoload_relative? https://github.com/ruby/ruby/pull/16148

[mame (Yusuke Endoh)]

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