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 log about the discussion to a 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 are scheduled according to when/where we can reserve Matz's time.
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.
Comment deadline: 2020/09/18 (one week before the meeting)
Introduces Module#descendants method as a native way to track Class/Module descendants, instead of inefficient hack like crawling ObjectSpace or tracking descendants via inherited hook. MRI already tracks subclasses, so this won't introduce new overheads.
[Feature #17056] Array#index: Allow specifying the position to start search as in String#index (fatkodima)
If we know from which offset to start searching, this will potentially speed up the index findings.
[Bug #17030] Enumerable#grep{_v} should be optimized for Regexp (fatkodima)
From this issue, it was decided to add a new /f ("fast", the name is debatable) option to regexps.
When provided, the methods which previously allocated global MatchData objects, won't do that anymore. This will reduce memory usage overall and greatly sped things up. The benchmark results are provided in the ticket.
[Feature #15573] Permit zero step in Numeric#step and Range#step (fatkodima)
This is for consistency with other behavior. The ticket description describes the problem. Matz responded there that, and I implemented a patch and chose to raise an error on zero step.
[Feature #13381] Expose rb_fstring and its family to C extensions
Still an extremely useful feature long awaited, it would be very disappointing if it didn't make it to 3.0.
Both json and msgpack-ruby agreed to a feature that calls String#-@ from C extensions. Meaning rb_fstring_cstr would allow them to saves lots of allocations.
[Bug #17178] Procs with kw:def/**kw lose elements when called with a single Array (eregon)
Does it sound buggy to you too? Do you think we can experiment and try changing it for Ruby 3? Current behavior seems useless, inconsistent and counter-intuitive.