April 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125143] [Ruby Misc#21968] The pathname gem needs a new release
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #21968 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21968: The pathname gem needs a new release https://bugs.ruby-lang.org/issues/21968 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- The current pathname gem release (0.4.0) has several issues: ### Many warnings on Ruby 4.0 It emits many constant & method redefinition warnings. This happens notably when an application has `pathname` as a dependency (direct or transitive) in the Gemfile. This is with the default `$VERBOSE`: ``` $ gem i pathname $ ruby -e 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here ``` And 53 warnings with `-w`: ``` $ ruby -we 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:50: warning: method redefined; discarding old chop_basename <internal:pathname_builtin>:359: warning: previous definition of chop_basename was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:61: warning: method redefined; discarding old split_names <internal:pathname_builtin>:370: warning: previous definition of split_names was here ... ``` See https://github.com/ruby/pathname/issues/66 ### The gem fails to install on JRuby See https://github.com/ruby/pathname/issues/94#issuecomment-4016566593 ### The gem crashes on TruffleRuby It causes errors like `pathname.so: undefined symbol: rb_block_call_kw`. See https://github.com/ruby/pathname/issues/94#issue-4038536603 ### Release request These 3 issues are fixed on ruby/pathname master by https://github.com/ruby/pathname/pull/56 and https://github.com/ruby/pathname/pull/57, but no release including those fixes has been published yet. I also opened a GitHub issue about the release request here: https://github.com/ruby/pathname/issues/94. Would it be possible to make a new pathname release? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125164] [Ruby Feature#21975] Add "UTF-八" as an alias for UTF-8 encoding
by ko1 (Koichi Sasada) 14 Apr '26

14 Apr '26

Issue #21975 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21975: Add "UTF-八" as an alias for UTF-8 encoding https://bugs.ruby-lang.org/issues/21975 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- In Japan, legal texts must write all characters - including digits - using full-width or kanji forms. As a result, the encoding name "UTF-8" appears as "UTF-八" (八 = eight in kanji) in official government notices. Specifically, it appears in a notice issued by the Digital Agency and the Ministry of Internal Affairs and Communications (令和8年デジタル庁・総務省告示第12号), which defines character sets and encoding for local government information systems: > 地方公共団体情報システムの標準化に関する法律第七条第一項に規定する各地方公共団体情報システムに共通する基準のうち電磁的記録において用いられる用語及び符号の相互運用性の確保その他の地方公共団体情報システムに係る互換性の確保に関する標準を定める命令第三条第二号の規定に基づき行政事務標準文字の文字セット及び地方公共団体情報システム間の連携のための文字符号化方式を定める告示 Reference: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resourc… This patch <https://github.com/ruby/ruby/pull/16623> adds "UTF-八" as an encoding alias for UTF-8, so that Ruby is compliant with Japanese law. ```ruby # encoding: UTF-八 p __ENCODING__ #=> #<Encoding:UTF-8> p Encoding.find("UTF-八") #=> #<Encoding:UTF-8> p "hello".encode("UTF-八") #=> "hello" p "こんにちは".force_encoding("UTF-八") #=> "こんにちは" p "こんにちは".encode("ＵＴＦ｜八") #=> "こんにちは" ``` -- https://bugs.ruby-lang.org/

5 5

[ruby-core:125253] [Ruby Bug#21997] segfault in basicobject
by danielchong (Daniel Chong) 13 Apr '26

13 Apr '26

Issue #21997 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #21997: segfault in basicobject https://bugs.ruby-lang.org/issues/21997 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ./ruby script.rb ``` [0, 1, -1, 10000000000000000000000, -10000000000000000000000].each do |val| begin class BasicObject def initialize(v); @v = v; end def to_s; @v.to_s; end end obj = BasicObject.new(val) p [:required_after, TOPLEVEL_BINDING.local_variables] s = val.to_s.force_encoding(Encoding::UTF_8) s.codepoints if s.valid_encoding? binding.eval("v = #{val}; [:test, v, TOPLEVEL_BINDING.local_variables]") rescue => e end end ``` `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. ==575066==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffd6e104000; bottom 0x55d86e96b000; size: 0x2a24ff799000 (46338393346048) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 d1d8e75b87fbf5baa84c:6: [BUG] Segmentation fault at 0x0000000000000094 ruby 4.1.0dev (2026-04-11T12:02:54Z master f70c081b8f) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0020 e:000019 l:y b:0001 r:(nil) CLASS d1d8e75b87fbf5baa84c:6 c:0004 p:0007 s:0017 e:000016 l:n b:---- r:(nil) BLOCK d1d8e75b87fbf5baa84c:5 [FINISH] c:0003 p:---- s:0010 e:000009 l:y b:---- r:(nil) CFUNC :each c:0002 p:0005 s:0006 e:000005 l:n b:---- r:(nil) EVAL d1d8e75b87fbf5baa84c:2 [FINISH] c:0001 p:0000 s:0003 E:001730 l:y b:---- r:(nil) DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- d1d8e75b87fbf5baa84c:2:in '<main>' d1d8e75b87fbf5baa84c:2:in 'each' d1d8e75b87fbf5baa84c:5:in 'block in <main>' d1d8e75b87fbf5baa84c:6:in '<class:BasicObject>' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055d86dbaee31 RBP: 0x00007ffd6e101cd0 RSP: 0x00007ffd6e101be0 RAX: 0x0000000000000004 RBX: 0x0000147aa3133980 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000147aa31339b0 RSI: 0x0000502000001590 R8: 0x0000000000000001 R9: 0x000051300000eef8 R10: 0x00007ffd6e101060 R11: 0x0000028f54626750 R12: 0x0000147aa3133a20 R13: 0x0000000000000001 R14: 0x0000028f54626730 R15: 0x0000000000000001 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /lib/x86_64-linux-gnu/libasan.so.8(___interceptor_backtrace+0x60) [0x147aa54c91e0] ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4358 /home/w023dtc/ruby/build/ruby(rb_print_backtrace+0x8) [0x55d86dfbc812] ../vm_dump.c:1108 /home/w023dtc/ruby/build/ruby(rb_vm_bugreport) ../vm_dump.c:1456 /home/w023dtc/ruby/build/ruby(rb_bug_for_fatal_signal+0x20d) [0x55d86e399ffd] ../error.c:1140 /home/w023dtc/ruby/build/ruby(sigsegv+0x88) [0x55d86dd994b8] ../signal.c:948 /lib/x86_64-linux-gnu/libc.so.6(0x147aa5086330) [0x147aa5086330] /home/w023dtc/ruby/build/ruby(rb_estimate_iv_count+0x211) [0x55d86dbaee31] ../iseq.c:3032 /home/w023dtc/ruby/build/ruby(RCLASS_SET_MAX_IV_COUNT+0x0) [0x55d86df7c06e] ../vm_insnhelper.c:6054 /home/w023dtc/ruby/build/ruby(vm_define_method) ../vm_insnhelper.c:6054 /home/w023dtc/ruby/build/ruby(vm_exec_core+0xac0) [0x55d86df89270] ../insns.def:837 /home/w023dtc/ruby/build/ruby(rb_vm_exec+0x2ee) [0x55d86df58c6e] ../vm.c:2810 /home/w023dtc/ruby/build/ruby(invoke_block_from_c_bh+0x6c6) [0x55d86df65b26] ../vm.c:1832 /home/w023dtc/ruby/build/ruby(rb_yield+0x1d1) [0x55d86df69451] ../vm.c:1883 /home/w023dtc/ruby/build/ruby(RB_FL_TEST_RAW+0x0) [0x55d86e1368ac] ../array.c:2766 /home/w023dtc/ruby/build/ruby(RB_FL_ANY_RAW) ../include/ruby/internal/fl_type.h:455 /home/w023dtc/ruby/build/ruby(rb_array_len) ../include/ruby/internal/core/rarray.h:259 /home/w023dtc/ruby/build/ruby(rb_ary_each) ../array.c:2765 /home/w023dtc/ruby/build/ruby(vm_cfp_consistent_p+0x0) [0x55d86df1cf96] ../vm_insnhelper.c:3914 /home/w023dtc/ruby/build/ruby(vm_call_cfunc_with_frame_) ../vm_insnhelper.c:3916 /home/w023dtc/ruby/build/ruby(vm_call_method_each_type+0x221) [0x55d86df5c101] ../vm_insnhelper.c:4900 /home/w023dtc/ruby/build/ruby(vm_call_method+0x2b4) [0x55d86df5f2d4] ../vm_insnhelper.c:5052 /home/w023dtc/ruby/build/ruby(vm_sendish+0x312) [0x55d86df3ba62] ../vm_insnhelper.c:6138 /home/w023dtc/ruby/build/ruby(vm_exec_core+0x8e6) [0x55d86df89096] ../insns.def:864 /home/w023dtc/ruby/build/ruby(rb_vm_exec+0x2ee) [0x55d86df58c6e] ../vm.c:2810 /home/w023dtc/ruby/build/ruby(rb_iseq_eval_main+0x18a) [0x55d86df9dcfa] ../vm.c:3106 /home/w023dtc/ruby/build/ruby(rb_ec_exec_node+0x2ab) [0x55d86da4ef0b] ../eval.c:284 /home/w023dtc/ruby/build/ruby(ruby_run_node+0xfe) [0x55d86da564ce] ../eval.c:322 /home/w023dtc/ruby/build/ruby(rb_main+0x21) [0x55d86da458f2] ../main.c:42 /home/w023dtc/ruby/build/ruby(main) ../main.c:62 /lib/x86_64-linux-gnu/libc.so.6(0x147aa506b1ca) [0x147aa506b1ca] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x147aa506b28b] [0x55d86da46f25] -- Other runtime information ----------------------------------------------- * Loaded script: d1d8e75b87fbf5baa84c * Ruby Box: disabled * Loaded features: 0 enumerator.so 1 monitor.so 2 thread.rb 3 fiber.so 4 rational.so 5 complex.so 6 pathname.so 7 ruby2_keywords.rb 8 set.rb AddressSanitizer:DEADLYSIGNAL Segmentation fault (core dumped) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125252] [Ruby Bug#21996] Crash when modifying instance variables during inspect or Marshal dump
by jhawthorn (John Hawthorn) 13 Apr '26

13 Apr '26

Issue #21996 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21996: Crash when modifying instance variables during inspect or Marshal dump https://bugs.ruby-lang.org/issues/21996 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In #15968 describes an issue where instance variables being modified lead to incorrect Marshal output being generated, which was partially solved by checking for the number of IVs changing and raising an exception. However, if enough IVs removed this could cause the buffer to be moved/re-embedded, but we'd still attempt to read the now removed variables. I've found this reproduces back to Ruby 3.3, but suspect there are other ways to hit issues on older versions. We've seen the test from #15968 start failing on CI recently (likely because the changes to size pools makes this crash reproducible) https://github.com/ruby/ruby/actions/runs/24247666394/job/70803324392 ``` ruby class Evil def initialize(parent) @parent = parent end def marshal_dump @parent.instance_variables.each { |v| @parent.remove_instance_variable(v) } {} end def marshal_load(data) = nil end obj = Object.new obj.instance_variable_set(:@evil, Evil.new(obj)) 10.times { |i| obj.instance_variable_set(:"@v#{i}", 0) } Marshal.dump(obj) # SEGV ``` ``` ruby class Evil def initialize(parent) @parent = parent end def inspect @parent.instance_variables.each { |v| @parent.remove_instance_variable(v) } "" end end obj = Object.new obj.instance_variable_set(:@evil, Evil.new(obj)) 10.times { |i| obj.instance_variable_set(:"@v#{i}", 0) } obj.inspect # SEGV ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125237] [Ruby Bug#21992] Defining BasicObject#initialize causes segmentation fault
by petercooper (Peter Cooper) 12 Apr '26

12 Apr '26

Issue #21992 has been reported by petercooper (Peter Cooper). ---------------------------------------- Bug #21992: Defining BasicObject#initialize causes segmentation fault https://bugs.ruby-lang.org/issues/21992 * Author: petercooper (Peter Cooper) * Status: Open * ruby -v: 4.0.2 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Simplest reproduction: ``` ruby class BasicObject def initialize end end ``` In Ruby HEAD, 4.0.2, 3.4.7, and 3.3.11 on macOS, this leads to an immediate segmentation fault. I also got this on Ruby 3.4.1 on Linux. What I would expect, a warning similar to that raised if you do the same on `Object`. I couldn't find a previous mention of this. It's not something you would ever write yourself, but I guess it could arise during metaprogramming or dynamic code generation with the right (wrong) constant name in play. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123836] [Ruby Feature#21695] Optimizing Ruby performance with Ruby itself instead of Rust
by fredlinhares (Frederico Linhares) 10 Apr '26

10 Apr '26

Issue #21695 has been reported by fredlinhares (Frederico Linhares). ---------------------------------------- Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust https://bugs.ruby-lang.org/issues/21695 * Author: fredlinhares (Frederico Linhares) * Status: Open ---------------------------------------- I am using ERB on top of C for a game I am making now. We can use the tool to improve the productivity, memory safety, and runtime speed for Ruby. It can also replace a Rust JIT compiler for better results. The only problem is that it requires some level of manual memory management, while Rust does it all for you. If I demonstrate that it is better than Rust in practice, would you be willing to incorporate it into the Ruby language? I want to know because making it more generic will require more effort from me; if you are not interested, I won’t make the tool public. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:125217] [Ruby Feature#21987] Assume `chdir(2)` isn't called and cache `rb_dir_getwd_ospath()`
by byroot (Jean Boussier) 10 Apr '26

10 Apr '26

Issue #21987 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21987: Assume `chdir(2)` isn't called and cache `rb_dir_getwd_ospath()` https://bugs.ruby-lang.org/issues/21987 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context I'm looking at optimizing Ruby applications boot time, and one very common operation that seems wasteful is that when interpreting relative paths we keep calling `ruby_getcwd()`, even though its result almost never changes (`Dir.chdir` calls are rare). We have 3 distinct implementations of `ruby_getcwd()` depending on the platform, but generally speaking it involves: - One or multiple syscalls (on macOS: `open` + `fnctl` + `stat` + `close`). - `malloc` + `free` - `strdup` + `free` - For some implementations, allocating a `T_DATA` to avoid leaks in case of failure. ### Measure Out of curiosity I measured our monolith. Just booting we end up calling `getcwd(2)` `6931` times, for a total of `90ms` spent in `rb_dir_getwd_ospath()`, but the caching would allow to save a bit more than that, as callers would no longer need to manage that memory. ### Proposal I propose that we cache the result of `ruby_getcwd()`, and only flush the cache when `Dir.chdir` is called. ### Compatibility concern This however assumes that C extensions or other native libraries never call `chdir(2)` after executing Ruby, or at least always reset it before yielding back to Ruby. I'm not aware of any C extension currently doing this, but it would be interesting to perform a `gem-codesearch`. If necessary we can provide `void ruby_cwd_changed(void)` to reset the cache after calling `chdir(2)`. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:125208] [Ruby Bug#21984] RubyVM::AST can't tell if an array is passed to break/next/return
by kddnewton (Kevin Newton) 09 Apr '26

09 Apr '26

Issue #21984 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21984: RubyVM::AST can't tell if an array is passed to break/next/return https://bugs.ruby-lang.org/issues/21984 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` irb(main):005> RubyVM::AbstractSyntaxTree.parse("tap { break [1, 2, 3] }") => (SCOPE@1:0-1:23 tbl: [] args: nil body: (ITER@1:0-1:23 (FCALL@1:0-1:3 :tap nil) (SCOPE@1:4-1:23 tbl: [] args: nil body: (BREAK@1:6-1:21 (LIST@1:12-1:21 (INTEGER@1:13-1:14 1) (INTEGER@1:16-1:17 2) (INTEGER@1:19-1:20 3) nil))))) irb(main):006> RubyVM::AbstractSyntaxTree.parse("tap { break 1, 2, 3 }") => (SCOPE@1:0-1:21 tbl: [] args: nil body: (ITER@1:0-1:21 (FCALL@1:0-1:3 :tap nil) (SCOPE@1:4-1:21 tbl: [] args: nil body: (BREAK@1:6-1:19 (LIST@1:12-1:19 (INTEGER@1:12-1:13 1) (INTEGER@1:15-1:16 2) (INTEGER@1:18-1:19 3) nil))))) irb(main):007> ``` The issue is, `break [1, 2, 3]` has the same AST as `break 1, 2, 3` (presumably because they are effectively the same thing). But a consumer has no way to know if an array was used short of re-parsing the source. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:125218] [Ruby Bug#21988] `return a, &b` should be syntax error
by tompng (tomoya ishida) 09 Apr '26

09 Apr '26

Issue #21988 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21988: `return a, &b` should be syntax error https://bugs.ruby-lang.org/issues/21988 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `return a, &b` is syntax error in parse.y, but accepted in Prism ~~~ruby Prism.parse_success?('return a, &b') #=> true RubyVM::AbstractSyntaxTree.parse('return a, &b') #=> block argument should not be given (SyntaxError) ~~~ When evaluated, block part is just ignored ~~~ruby ->{return (p :arg_part), **(p kwsplat_part:1), &(p :block_part)}.call # :arg_part # {kwsplat_part: 1} #=> [:arg_part, {kwsplat_part: 1}] ~~~ -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125192] [Ruby Feature#21982] Add `Decimal` as a core numeric class
by shan (Shannon Skipper) 08 Apr '26

08 Apr '26

Issue #21982 has been reported by shan (Shannon Skipper). ---------------------------------------- Feature #21982: Add `Decimal` as a core numeric class https://bugs.ruby-lang.org/issues/21982 * Author: shan (Shannon Skipper) * Status: Open ---------------------------------------- # Feature: Add `Decimal` as a core numeric class ## Abstract Add `Decimal < Numeric` to Ruby core: exact base-10 arithmetic using a tagged immediate VALUE (like Fixnum) for small values, promoting to a 128-bit heap object for larger values. ## Background Ruby apps that handle money, tax rates or measurements often use Integers with extra business logic since Float can't represent most base-10 fractions exactly: ```ruby 0.1 + 0.2 == 0.3 #=> false 0.1 + 0.2 #=> 0.30000000000000004 0.1d + 0.2d == 0.3d #=> true 0.1d + 0.2d #=> 0.3d ``` Alternatives have tradeoffs: - **BigDecimal**: correct but 8x slower than Float on compound interest. - **Rational**: correct but equally slow, and `Rational("19.99").to_s` gives `"1999/100"`. - **Integer cents**: correct and fast but pushes formatting and decimal-point tracking into application code. ## Proposal ```ruby # Literal syntax price = 19.99d tax_rate = 0.0875d total = (price * (1d + tax_rate)).round(2) #=> 21.74d # Kernel converter (like Integer(), Float()) Decimal("29.99") #=> 29.99d Decimal(42) #=> 42.0d # Value semantics: frozen, Ractor-shareable 19.99d.frozen? #=> true # Full numeric protocol 19.99d + 1 #=> 20.99d 19.99d <=> 20.0d #=> -1 19.99d.round(1) #=> 20.0d # Human-focused string interpolation "$#{19.99d}" #=> "$19.99" "$#{BigDecimal("19.99").to_s("F")}" #=> "$19.99" ``` ### Features - **`d` literal suffix**: `42d`, `3.14d`, `0.1d` (matching `r` for Rational, `i` for Complex) - **Frozen and Ractor-shareable**: value semantics like Rational - **18 decimal places**: fixed precision, full signed 128-bit range - **`Kernel#Decimal()` converter**: with `exception: false` support - **Full numeric protocol**: arithmetic, comparison, coercion, rounding, `to_i`/`to_f`/`to_r`/`to_s`, pattern matching ## Performance Apple M4 with YJIT. All values pre-allocated outside the measurement loop. ### Compound interest: 360 monthly iterations `balance = (balance * (1 + rate)).round(2)` repeated 360 times. A tight loop of multiply, add, round. Both Decimal and Float produce $60,225.61. | Type | YJIT | No JIT | |------|------|--------| | Decimal (BID) | 93K i/s | 55K i/s | | Float | 83K i/s | 60K i/s | | Rational | 10.7K i/s | 9.4K i/s | | BigDecimal | 10.1K i/s | 9.3K i/s | With YJIT, Decimal is 1.12x faster than Float on compound interest. Without YJIT, Float is 1.1x faster. YJIT helps Decimal more (1.7x speedup vs Float's 1.4x) because BOPs and unchecked entry points skip the per-call type checks. Rational and BigDecimal are ~9x slower than Decimal either way. ### Per-operation (benchmark-driver, YJIT) | Operation | Decimal (BID) | Float | Ratio | |-----------|---------------|-------|-------| | add | 147M i/s | 160M i/s | 1.09x slower | | mul | 159M i/s | 158M i/s | ~parity | | round(2) | 118M i/s | 78M i/s | 1.5x faster | | div (inexact) | 49M i/s | 140M i/s | 2.9x slower | | parse | 34M i/s | 34M i/s | parity | | to_s | 32M i/s | 9M i/s | 3.4x faster | | sum(1000) | 1.27M i/s | 794K i/s | 1.6x faster | Add and mul are near Float parity. Round is 1.5x faster, to_s 3.4x faster. Division is 2.9x slower (inexact results need wide arithmetic). ## Design Two-tier storage, mirroring Fixnum/Bignum: ``` Significand <= 2^51 - 1: 8 bytes, no allocation 63 62 12 11 8 7 0 +---+------------------------+-----+-------+ | 0 | 1999 | 2 | 0x84 | +---+------------------------+-----+-------+ sign significand (51 bits) scale tag 64 bits encode sign, significand, decimal position and type tag. The value IS the VALUE, like Fixnum. All 15-digit significands fit. Some 16-digit significands fit (up to 2,251,799,813,685,247). Significand > 2^51 - 1: heap allocated +--------+ +----------------+----------------+--------------------------------+ | ptr | --> | flags + klass | value * 10**18 | +--------+ | 16 bytes | 16 bytes | VALUE +----------------+----------------+--------------------------------+ 8 bytes object header full i128 range, 18 decimal places Standard Ruby object header with embedded i128 payload. ``` `Decimal("12.34")` is an immediate. No object, no allocation, no GC. `Decimal("9_999_999_999_999_999.99")` promotes to heap (significand exceeds 51 bits). `Decimal("123_456_789_012_345_678_901_234_567_890_123_456.78")` raises RangeError (exceeds 128-bit range). ### Optimization layers The prototype implements analogous layers to Float and Integer: - 13 BOPs with `DECIMAL_REDEFINED_OP_FLAG` - Interpreter fast paths in `vm_opt_plus/minus/mult/div/mod`, `vm_opt_lt/le/gt/ge`, `opt_equality_specialized` - YJIT `Type::Decimal` with inline BID add/sub and BOP guard paths - ZJIT `types::Decimal` with profiler support and method annotations - Unchecked `_dd` entry points for YJIT and interpreter - Reciprocal lookup tables for division-free scale reduction ### Heap arithmetic Heap multiply and divide use 256-bit widening (same algorithm as Roc). Optional fast paths exploit the fact that SCALE (10^18) fits in u64: schoolbook two-division `wide_div`, single-operand `wide_mul_64` and Barrett reduction for the u128 case. These improve heap multiply by ~25% and heap division by ~50%. All are removable without affecting correctness or BID performance. ## Type coercion When Decimal interacts with other numeric types: ```ruby 1.5d + 1 #=> 2.5d (Integer promotes to Decimal) 1.5d + 0.5 #=> 2.0 (Decimal demotes to Float) 1.5d + 1/4r #=> 1.75d (Rational promotes to Decimal) 1.5d + 1/3r # ArgumentError (1/3 exceeds 18 decimal places) 1.5d == 1.5 #=> true (compared via Rational) 1.5d == 3/2r #=> true (Rational comparison via <=>) ``` Decimal + Integer returns Decimal (lossless). Decimal + Float returns Float (caller chose approximate arithmetic). Decimal + Rational returns Decimal when the Rational is exactly representable in 18 decimal places, raises ArgumentError otherwise. Conversion is exact. Only arithmetic results (`*`, `/`) truncate. ## Relationship to BigDecimal Decimal and BigDecimal serve different needs: - **Decimal**: fixed precision (18 places), core type, immediate encoding, JIT-optimized. For the common case: prices, percentages, measurements. - **BigDecimal**: arbitrary precision, bundled gem, heap-allocated. For when you need more than 18 decimal places or unbounded digit counts. They can coexist. The Decimal conversion method is `to_dec` to avoid conflict with `bigdecimal/util`, which defines `to_d`. If `to_d` can be shared or BigDecimal's deprecated, `to_d` would be more natural. ## Why two Decimal tiers Intel's BID64 gives a 64-bit immediate with 16 digits. Roc's Dec gives a 128-bit fixed-point value with 39 digits. Both are proven designs. Ruby's approach combines them, the same way Integer combines Fixnum and Bignum. Small values are immediates, large ones promote to heap. Transparent to the programmer. Two simpler alternatives are also viable: - **BID-only**: 15-16 digits (51-bit significand), zero allocation. Operations exceeding the BID range would raise. Half the code. - **i128-only**: 39 digits, one allocation per decimal. No dual paths. Simpler but slower with GC churn. ## Design details - **Fixed 18 decimal places**: 10^18 fits in a 64-bit integer, keeping the SCALE factor cheap for multiplication and division. 18 places cover all ISO 4217 currency subdivisions. - **Truncation toward zero for `*` and `/`**: consistent with C integer division. Floored division for `%`, `div`, `divmod` (matching Ruby's Integer). - **Exact input conversion**: `Decimal("1e-19")` raises `ArgumentError` because the value cannot be represented in 18 decimal places. `Decimal("1e-19", exception: false)` returns `nil`. Trailing zeros beyond 18 places are accepted: `Decimal("1.10000000000000000000")` is `1.1d`. Arithmetic truncation is separate and expected. - **Float conversion via `Float#to_s` then parse**: `Decimal(0.1)` gives `0.1d`, not `0.1000000000000000055...d`. - **`0d` is a Decimal literal**: `0d` produces `Decimal(0)`. `0d42` remains `Integer(42)` (the existing decimal-integer prefix). `0D42` also remains `Integer(42)` (only lowercase `d` produces Decimal). - **Frozen and Ractor-shareable**: like Rational. No mutable state. ## Portability The prototype requires `__int128` (GCC and Clang). For the heap variant, MSVC would need a two-word i128 emulation or a pure-C fallback using `int64_t hi, lo` fields along with appropriate operations. The BID immediate tier (64-bit only) works everywhere. ## Scope Implementation (`decimal.c`, `decimal.rb`), VM fast paths, YJIT and ZJIT type tracking and codegen, serialization, Kernel converters and `prism_compile.c`. The `d` literal suffix requires a small Prism upstream change (~60 lines in `prism.c` plus regenerated sources). Psych would need a separate patch for YAML serialization. Both would be submitted as upstream PRs if this proposal is accepted. ## Gem A gem version provides the same semantics as a C extension with pure Ruby fallback. It gets 14.2K i/s on compound interest with YJIT, versus core Decimal's 93K (6.5x slower). A gem cannot add VALUE tag bytes, register BOPs or teach YJIT new types, so it must heap-allocate every result and go through full method dispatch. ## Related work | Language | Type | Encoding | Precision | Normalized | |----------|------|----------|-----------|------------| | Intel libbid | BID64 | 1+13+50 combination field | 16 digits | no (cohorts) | | Intel libbid | BID128 | 1+17+110 floating-point | 34 digits | no (cohorts) | | Roc | Dec | i128 fixed-point (* 10^18) | 39 digits | n/a (fixed scale) | | C# | System.Decimal | 96-bit sig + 5-bit scale | 28-29 digits | no | | Ruby | Decimal (this) | 51-bit immediate + i128 heap | 15-16 digits (BID), full i128 (heap) | yes (canonical) | **Immediate tier vs Intel BID64**: Intel's combination-field encoding gets 16 digits from 64 bits (vs our 15-16) by implicitly encoding the leading significand digit. The cost is decoder complexity and unnormalized cohorts. `1.0` and `1.00` have different bit patterns, requiring rescaling for equality. Our BID encoding strips trailing zeros for a canonical form: equal immediates are always identical bit patterns, so equality is a single-word comparison. Heap decimals use i128 value comparison. **Heap tier vs Roc Dec**: nearly identical design. Same i128 scaled by 10^18, same 256-bit widening for multiply and divide. Our additions: reciprocal lookup tables for division-free scale reduction, Barrett reduction for the SCALE division and promotion to the immediate tier when results fit. **Both tiers vs C# System.Decimal**: C# uses a 96-bit significand with variable scale 0-28 in a single 128-bit value type. More precision (28-29 digits) than our immediate but no fast path. All arithmetic operates on three 32-bit words. Not normalized. Ruby doesn't have value types, so C#'s stack-allocation advantage doesn't apply. The tagged immediate achieves the same effect. Like Integer, the two tiers are invisible in Rubyland. A Decimal is a Decimal. https://github.com/ruby/ruby/pull/16659 -- https://bugs.ruby-lang.org/

6 9