Ruby Issue Tracking System

11/05/2025

03:34 PM Ruby Misc #21657: Question: Is Ruby 4.0 planned for December 2025 or later?

Just adding my two cents to the off-topic discussion.
I honestly feel that the `~>` constraint was a terrible idea. It's going to be a huge pain when Ruby 4.0 is released (at the end of this year, perhaps?), and all the gems locked to... mame (Yusuke Endoh)

03:13 PM Ruby Bug #21659: rstring.h error: missing initializer for field ‘len’ of ‘struct RString’ [-Werror=missing-field-initializers] starting in ruby-3.3.10

Fun C topic!
wsfulton (William Fulton) wrote in #note-8:
> A more conventional way for default aggregate initialisation is
> ...
Unfortunately, that empty initializer is a violation of the C99 language specification. You can confir... mame (Yusuke Endoh)

02:45 PM Ruby Bug #21669: Thoroughly implement void value expression check

Eregon (Benoit Daloze) wrote in #note-1:
> This check is getting more and more complicated and I wonder of the value of having it.
IMO, the current is indeed complicated because it is inconsistent. I think the new behavior is consist... mame (Yusuke Endoh)

11:08 AM Ruby Bug #21669 (Open): Thoroughly implement void value expression check

A void-value-expression check is a syntax check that raises a `SyntaxError` if an expression that cannot grammatically return a value (a "void value expression," such as a `return` expression) appears in a context where a value is expect... mame (Yusuke Endoh)

10/31/2025

07:15 AM Ruby Bug #21654: Set#new calls extra methods compared to previous versions

I understand your point, but I personally disagree.
My concern is that the expectation to "if it's at all possible to raise early" is a slippery slope with no clear boundary.
For example, an operation like `(1..1<<100).to_a` will a... mame (Yusuke Endoh)

10/30/2025

04:20 PM Ruby Bug #21654: Set#new calls extra methods compared to previous versions

Dan0042 (Daniel DeLorme) wrote in #note-7:
> What that really what you meant by "checking if Range#end is nil is good enough" ?
Yes. The original issue (#21513) was about the consistency between `(1..).to_a` and `(1..).to_set`. Since... mame (Yusuke Endoh)

10/29/2025

01:57 AM Ruby Bug #21654: Set#new calls extra methods compared to previous versions

>　How about handling only `Range` and `Enumerator` (not `Enumerable`) for now?
I think it would be better to handle only Range for now, and not Enumerator either. See https://bugs.ruby-lang.org/issues/21513#note-10 mame (Yusuke Endoh)

01:52 AM Ruby Bug #21513 (Open): Converting endless range to set hangs

The fix introduced another inconsistency:
```
$ ruby -e 'Enumerator.new(Float::INFINITY) {|g| loop { g << 1 } }.to_set'
-e:1:in 'Enumerable#to_set': cannot initialize Set from an object with infinite size (ArgumentError)
fr... mame (Yusuke Endoh)

10/28/2025

09:29 AM Ruby Feature #21650 (Feedback): Performance regression: Rational#floor(ndigits) extremely slow for huge ndigits in Ruby 3.4 (ok in 3.2)

Thank you for your reply.
I found a clearer case:
```ruby
p Rational(1, 3).floor(2**1) #=> (33/100)
p Rational(1, 3).floor(2**2) #=> (3333/10000)
p Rational(1, 3).floor(2**3) #=> (33333333/100000000)
p Rational(1, 3).floor(2**4... mame (Yusuke Endoh)

09:03 AM Ruby Feature #21650: Performance regression: Rational#floor(ndigits) extremely slow for huge ndigits in Ruby 3.4 (ok in 3.2)

Thank you for the report.
As the warning indicates, prior to Ruby 3.4 (up to 3.3), attempting to generate a huge `Integer` would return `Float::INFINITY`. Ruby 3.4 removed this inaccurate truncation, which is why it now takes longer. (#... mame (Yusuke Endoh)