Misc #21281: DevMeeting-2025-05-08

• Status: Open
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

Date: 2025/05/08 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 2025/05/05. 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 #15408] Actually deprecate ObjectSpace._id2ref (byroot)
  • Matz agreed to deprecate _id2ref for Ruby 2.7 but that was never implemented.
  • I have a PR open to finally do it, but should the deprecation mention the removal timeline, is there one?
  • The main user is drb but there is a PR open to solve it: https://github.com/ruby/drb/pull/31

[tagomoris (Satoshi Tagomori)]

• Namespace on read
  • I'm finishing the namespace branch to be ready for merge (disabled by default) https://github.com/tagomoris/ruby/tree/namespace-on-read-classext
    • Feature #21311
    • https://github.com/ruby/ruby/pull/13226
  • Current status:
    • Default (Namespace disabled, YJIT/ZJIT disabled): make check and make exam passed on my macOS (not checked on CI)
    • Namespace enabled: make check passed but make exam failed (the known cause and I'll update the implementation soon)
  • I hope it'll be merged without further more rebases :P

[jeremyevans0 (Jeremy Evans)]

• [Feature #21274] Show performance warnings for easily avoidable unnecessary implicit splat allocations (jeremyevans0)
  • This warning only shows method calls that are allocating unnecessarily, where allocation can be avoided by using a local variable.
  • This warning found unnecessary allocations in the standard library, rubygems, Rails, and Sequel.
  • We are currently only using performance warnings for objects with too many shapes.
  • Is this OK to commit?
• [Feature #21287] Remove SortedSet autoload and set/sorted_set (jeremyevans0)
  • Set is now a core class, and the SortedSet autoload that was in set.rb is now in core.
  • This autoload only works if the sorted_set gem is installed.
  • I don't think we should have this autoload, can we remove it?
  • If so, do we want to deprecate the autoload before removing it?
• [Bug #21302] Remove or Fix Set#to_h (jeremyevans0)
  • The method was not present in stdlib Set, and not previously approved for addition.
  • However, psych started using it.
  • The method is not backwards compatible with the previous Set#to_h (implemented by Enumerable#to_h).
  • I recommend we remove it and fix psych, and have a pull request for that.
  • If we want to keep it, I have a pull request to fix it, and add tests and documentation.
  • Do we want to keep Set#to_h and have a return a true-valued hash if not given a block?
• [Bug #21280] StringIO#set_encoding warns when backed by chilled string literal (jeremyevans0)
  • This warning is bogus, as most code using this does not need changes when string literals are frozen.
  • Issuing bogus warnings prompts for unnecessary code changes and should be avoided.
  • StringIO#set_encoding already does not set the encoding if the string is frozen, since [Bug #11827]
  • I recommend we stop setting the underlying encoding for non-frozen strings to avoid the warning.
  • This could be done for only chilled strings, or for all strings if behavior should be consistent.
  • Should we make this change, and if so, for chilled strings or for both chilled and unfrozen strings?

[mame (Yusuke Endoh)]

• [Feature #21307] A way to strictly validate time input (mame)
  • I want to confirm that the current tolerant behavior of Time.new is intentional, and if so, want a strict variant of Time.new.

[jhawthorn (John Hawthorn)]

• [Feature #21267] respond_to check in Class#allocate is inconsistent
  • Class#allocate does a slow respond_to check to try to prevent uninitialized values via method(:allocate).bind_call on MatchData, Refinement, Module, Complex, Rational
  • The respond_to check is easy to trick and bypass. Even if it was more strict, it does not seem to provide additional safety as there are other ways to construct uninitialized objects.
  • Is it OK to remove?