Misc #21379: DevMeeting-2025-06-05

• Status: Closed
• Assignee: -

[hsbt (Hiroshi SHIBATA)]

The next dev meeting

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

[hsbt (Hiroshi SHIBATA)]

• Related to Misc #14770: [META] DevelopersMeeting added

[k0kubun (Takashi Kokubun)]

• [Misc #21369] Propose Max Bernstein (@tekknolagi (Maxwell Bernstein)) as a core committer (k0kubun)
  • It's detrimental to our productivity that such a core contributor isn't a committer. I want him to merge his PRs himself.

[matheusrich (Matheus Richard)]

• [Feature #21346] Introduce String#ensure_suffix
  • Is the naming good?
  • If approved, should String#ensure_prefix be added as well?
• [Feature #21386] Introduce Enumerable#join_map
  • I felt the need of something like this in several projects, and there are multiple examples of open source that would benefit from it. Can we approve the idea?

[jeremyevans0 (Jeremy Evans)]

• [Feature #21389] Simplify Set#inspect output (jeremyevans0)
  • I think Set#inspect should produce output similar to Array#inspect, not Object#inspect.
  • Is using Set[1, 2, 3] for Set#inspect acceptable?
  • Regardless of whether we change inspect output, do we want to include subclass name in inspect output ([Bug #21377])?
• [Feature #21390] Deprecate passing arguments to Set#to_set and Enumerable#to_set (jeremyevans0)
  • Array#to_a, Enumerable#to_a, Hash#to_h, Enumerable#to_h do not operate this way.
  • This currently allows passing non-Set subclasses, with undesirable results.
  • Can we deprecated in Ruby 3.5 and remove in Ruby 3.6?
• [Bug #21375] Set[] does not call #initialize (jeremyevans0)
  • It was a deliberate design decision in core Set to call C functions directly and not use method dispatch.
  • Hash.[] and Array.[] do not call Hash#initialize or Array#initialize, so Set behavior is consitent with that.
  • There are many other places where core Set methods do not call other Set methods.
  • For example, Set#initialize calls Set#add and Set#merge in stdlib Set, but not in core Set.
  • Unless we plan to restore all internal method calls (undesirable for performance and inconsistent with other core classes), I don't think we should make this change.
  • Can we close this?
• [Bug #21376] Inconsistent equality between Sets with different compare_by_identity, different classes (jeremyevans0)
  • I belive this is a bug in stdlib Set that I fixed in core Set.
  • Can we close this?

[Eregon (Benoit Daloze)]

• [Misc #21385] Namespace: Suggesting a rename (eregon)
  • "Namespace" seems to confuse many people (that feature is not about namespacing, modules do that, but about multiple execution contexts with their own $LOAD_PATH, $LOADED_FEATURES, copy of core classes, etc).
  • Can we think of another name for that feature?
  • How about Context or Ruby::Context?

[shioimm (Misaki Shioi)]

• [Feature #21347] Add open_timeout as an overall timeout option for Socket.tcp
  • I propose introducing an option to Socket.tcp that raises a timeout exception after a specified period has elapsed since the method started.
  • If approved, is it ok to implement this to TCPSocket.new as well?

[mame (Yusuke Endoh)]

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