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

[ruby-core:125156] [Ruby Feature#21972] Add Date.birthday and Date.age to track Ruby's milestones
by jinroq (Jinroq SAITOH) 12 Jun '26

12 Jun '26

Issue #21972 has been reported by jinroq (Jinroq SAITOH). ---------------------------------------- Feature #21972: Add Date.birthday and Date.age to track Ruby's milestones https://bugs.ruby-lang.org/issues/21972 * Author: jinroq (Jinroq SAITOH) * Status: Open ---------------------------------------- Since its inception in 1993, Ruby has grown beyond a mere programming language to become a rich culture beloved by developers worldwide. However, the standard `date` library surprisingly lacks a formal interface to commemorate Ruby's own historical milestones. The fact that developers cannot programmatically reference Ruby’s heritage is a missed opportunity to foster affection and respect for the language's identity. To rectify this historical oversight, I propose adding the following methods to reference Ruby's key anniversaries and calculate the elapsed years. #### New Features * **`Date.birthday(version = nil)`** Returns the "birthday" of significant moments in Ruby's history. * `nil` (default): **1993-02-24** (The day the name "Ruby" was decided). * `0.95`: **1995-12-21** (The first public release date). * `1.0`: **1996-12-25** (The first stable release date). * **`Date.age(version = nil)`** Calculates the current age (in full years) based on today's date and the specified milestone. * `Date.age`: Years since the name "Ruby" was born. * `Date.age(0.95)`: Years since Ruby was first introduced to the public as OSS. * `Date.age(1.0)`: Years since Ruby began its journey as a stable language. #### Usage Example ```ruby # Check the "age" of each edition puts "Name age: #{Date.age}" # => 33 (as of 2026) puts "OSS age: #{Date.age(0.95)}" # => 30 puts "Stable: #{Date.age(1.0)}" # => 29 # Perform a special action on a specific anniversary if Date.today == Date.birthday(1.0) celebrate_stable_anniversary! end ``` #### Implementation and Testing The attached patch (`birthday_and_age.patch`) includes the implementation of these methods along with a rigorous test suite (`test/date/test_date_birthday.rb`). The tests cover argument dispatching, `ArgumentError` for invalid inputs, and edge cases for age calculation (e.g., boundaries before and after the actual birthday), ensuring production-level quality. Equipping Ruby with the intelligence to reflect upon its own origins is a vital step toward the next 30 or 40 years of its evolution. (Note: This proposal was submitted on a special day that encourages looking at our history with both deep respect and a touch of creative imagination, as is traditional for such a significant date in the calendar.) ---Files-------------------------------- birthday_and_age.patch (8.08 KB) -- https://bugs.ruby-lang.org/

5 8

[ruby-core:125157] [Ruby Feature#21973] Smile argument
by kinoppyd (Yasuhiro Kinoshita) 11 Jun '26

11 Jun '26

Issue #21973 has been reported by kinoppyd (Yasuhiro Kinoshita). ---------------------------------------- Feature #21973: Smile argument https://bugs.ruby-lang.org/issues/21973 * Author: kinoppyd (Yasuhiro Kinoshita) * Status: Open ---------------------------------------- Ruby makes us smile. So I want Ruby to smile too, and that is why I would like to propose this feature. The smile argument makes Ruby smile by allowing a method call to end its argument list with `:)`. smile_method(arg, :) This syntax implicitly supplies keyword arguments by matching the names of local variables in the current scope with the names of the method’s keyword parameters. For example, if a method has the following signature: ```ruby some_method(arg, smile:, hugging:) ``` then these two calls would be equivalent: ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, smile:, hugging:) ``` ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, :) ``` The motivation behind this feature is the assumption that names used in a method signature are often also used at the call site. For instance, if a library method defines keyword arguments like `(from:, to:)`, I expect that code using that method would often have local variables named `from` and `to` holding the actual values before passing them along. In real application development, when developers adopt a new library, they will usually look at the argument list of the method they want to call. If they intend to use that method as designed, it seems natural that they may also choose the same variable names as those in the method signature. This idea was inspired by Scala’s implicit parameters. It is not exactly the same feature, but as a lazy person, I find the idea of context-driven currying quite appealing. In any case, the real purpose is to make Ruby smile. Happy Ruby! And happy April Fools' Day! -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125572] [Ruby Bug#22080] `Integer(obj, exception: false)` raises when `to_str` doesn't return String
by Earlopain (Earlopain _) 11 Jun '26

11 Jun '26

Issue #22080 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22080: `Integer(obj, exception: false)` raises when `to_str` doesn't return String https://bugs.ruby-lang.org/issues/22080 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-23T13:04:55Z master 6c6df00bbc) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb obj = Object.new def obj.to_str = 1 Integer(obj, exception: false) # can't convert Object to String (Object#to_str gives Integer) (TypeError) ``` But returning the wrong type from `to_int` is fine: ```rb obj = Object.new def obj.to_int = "1" Integer(obj, exception: false) # nil ``` Doc says this (https://docs.ruby-lang.org/en/master/Kernel.html#method-i-Integer) > With exception given as false, an exception of any kind is suppressed and nil is returned. So it looks like it should not raise in both cases. Or more specifically, try `to_i` next, since that is what happens when `to_int` returns the wrong type. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123958] [Ruby Feature#21720] Add a native Binary Heap / Priority Queue to Ruby's Standard Library (heapify, heappush, heappop)
by rahulk501 (Rahul Kumar) 11 Jun '26

11 Jun '26

Issue #21720 has been reported by rahulk501 (Rahul Kumar). ---------------------------------------- Feature #21720: Add a native Binary Heap / Priority Queue to Ruby's Standard Library (heapify, heappush, heappop) https://bugs.ruby-lang.org/issues/21720 * Author: rahulk501 (Rahul Kumar) * Status: Open ---------------------------------------- **Title:** Add a native Binary Heap / Priority Queue to Ruby's Standard Library (`heapify`, `heappush`, `heappop`) **Problem** Ruby currently lacks a native binary heap / priority queue data structure in the standard library. Users frequently reimplement heaps manually, or install third-party gems, simply to access common operations such as: * `heapify` * `heappush` * `heappop` * efficient priority queues Meanwhile, languages like Python provide a standard `heapq` module which is widely used in algorithms, AI, scheduling, job queues, pathfinding, graph traversal, and competitive programming. Because Ruby does not include a heap implementation, developers often write ad-hoc, buggy, or inconsistent versions of a heap. This leads to fragmentation and duplication. **Proposal** Introduce a lightweight `Heap` or `BinaryHeap` class to Ruby’s standard library with the following minimal API: ```ruby heap = Heap.new(array = []) heap.push(value) heap.pop # returns smallest (min-heap) heap.peek heap.size ``` Or a module-based functional API similar to Python’s `heapq`: ```ruby Heap.heapify(array) Heap.heappush(array, value) Heap.heappop(array) ``` Both designs are simple and allow backward-compatible extension. **Why include it in the standard library?** 1. Heaps are a *fundamental data structure*—used in sorting, algorithms, scheduling, and timers. 2. Many languages include them natively (Python, C++ via STL `priority_queue`, Java, Go, Rust `BinaryHeap`). 3. Adding it reduces unnecessary reimplementations in user codebases. 4. A small heap implementation adds little maintenance burden. 5. Existing Ruby solutions (gems like `algorithms`, `priority_queue`, custom code) are not universally available and often exceed what users need. **Reference Implementation (pure Ruby, minimal example)** ```ruby module Heap def self.heapify(arr) (arr.length / 2 - 1).downto(0) { |i| sift_down(arr, i) } arr end def self.heappush(arr, value) arr << value sift_up(arr, arr.length - 1) end def self.heappop(arr) return nil if arr.empty? arr[0], arr[-1] = arr[-1], arr[0] min = arr.pop sift_down(arr, 0) min end def self.sift_up(arr, i) while i > 0 p = (i - 1) / 2 break if arr[p] <= arr[i] arr[p], arr[i] = arr[i], arr[p] i = p end end def self.sift_down(arr, i) n = arr.length loop do left = 2 * i + 1 right = 2 * i + 2 smallest = i smallest = left if left < n && arr[left] < arr[smallest] smallest = right if right < n && arr[right] < arr[smallest] break if smallest == i arr[i], arr[smallest] = arr[smallest], arr[i] i = smallest end end private_class_method :sift_up, :sift_down end ``` **Optional C implementation** If accepted, I am willing to provide a minimal C version for performance parity with other stdlib containers. **Compatibility** No breaking changes expected. Naming avoids conflict with existing libraries. **Conclusion** Adding a tiny, well-defined heap structure would strengthen Ruby’s built-in algorithmic tools, reduce duplicated code across the ecosystem, and align Ruby with other mainstream languages. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument
by shioyama (Chris Salzberg) 10 Jun '26

10 Jun '26

Issue #19633 has been reported by shioyama (Chris Salzberg). ---------------------------------------- Feature #19633: Allow passing block to `Kernel#autoload` as alternative to second `filename` argument https://bugs.ruby-lang.org/issues/19633 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#autoload` takes two arguments, a symbol `module` representing the constant to be autoloaded, and a `filepath` to load the constant from (with `require`). Currently, Zeitwerk has to [monkeypatch `Kernel#require`](https://github.com/fxn/zeitwerk/blob/a7c4a983df0f4e4058f32c610dac1e8b99f687da/lib/zeitwerk/kernel.rb) to fetch the loader for the file being loaded, then run the original (aliased) `require`, then run autoload callbacks. In addition to the monkeypatch, this also requires a registry (`Zeitwerk::Registry`) to map file paths to loaders, to know which loader should be used for a given autoload-triggered `require`. In fact, Zeitwerk has to _assume_ that the monkey-patched `require` call came from an autoload trigger; there is no way to really be sure of the source. If Ruby allowed passing a block as an alternative to the explicit filepath, then I think this could be improved and would eliminate the need for a monkeypatch. So something like this: ```ruby autoload(:B) do require "lib/b" # trigger callback, etc end ``` I am implementing a gem called [Im](https://github.com/shioyama/im) which is a fork of Zeitwerk, and in the case of this gem, such a feature would be even more useful. Im implements autoloads on anonymous modules by registering an autoload and then "catching" the require and converting it into a `load`, passing the module as the second argument (see [here](https://github.com/shioyama/im/blob/44ce348639a1aae563a5be7a40602761e….) This is currently quite tricky because, again, it's hard to know _where_ a `require` came from. In addition to removing the monkeypatch (inherited from Zeitwerk), Im would further benefit from the block argument because then it could simply access the module via a closure, rather than pulling it from a registry: ```ruby mod.autoload(:Foo) do load "lib/foo.rb", mod end ``` I don't know how hard or easy this would be to implement, but if there is interest in this as a feature I'd be happy to look into implementing it. -- https://bugs.ruby-lang.org/

4 16

[ruby-core:125575] [Ruby Feature#22081] Core type definition migration from `ruby/rbs` to `ruby/ruby`
by soutaro (Soutaro Matsumoto) 09 Jun '26

09 Jun '26

Issue #22081 has been reported by soutaro (Soutaro Matsumoto). ---------------------------------------- Feature #22081: Core type definition migration from `ruby/rbs` to `ruby/ruby` https://bugs.ruby-lang.org/issues/22081 * Author: soutaro (Soutaro Matsumoto) * Status: Open * Assignee: soutaro (Soutaro Matsumoto) * Target version: 4.1 ---------------------------------------- Currently, the RBS type definitions for core libraries live in the `ruby/rbs` repository. When you change a core class or method in `ruby/ruby`, the corresponding RBS type definition often needs to be updated too — but that update requires a separate PR to `ruby/rbs`, so the work cannot be completed within `ruby/ruby` alone. This is painful for Ruby core committers and contributors. To address this problem, we will move the core library type definitions to `ruby/ruby` so that you can update the RBS type definitions within the same PR. We want to get this done in Ruby 4.1. **Question:** Do you have any concerns about migrating the RBS core type definitions to `ruby/ruby`? ## Current workflow The `test-bundled-gems` CI job in `ruby/ruby` runs the core type definition tests bundled with the rbs-gem. The tests actually call core methods and validate that the arguments and return values have the expected types using `is_a?`. When you change a core library in `ruby/ruby` in a way that requires a type definition update, the `test-bundled-gems` job fails and CI turns red. At that point, you have two options: 1. **Update the RBS type definitions** by submitting a separate PR to `ruby/rbs` 2. **Skip the failing tests** by adding the test name to the `rbs_skip_tests` file (in `ruby/ruby` repository) Either way, you are forced to take some action to get CI green again. Option 1 is actually very painful in practice. The type definitions bundled with the rbs-gem correspond to the released version of Ruby, not the in-development version. As a result, PRs to `ruby/rbs` for in-development APIs often end up modifying tests rather than type definitions — wasteful and frustrating work. Some examples: https://github.com/ruby/rbs/pull/2366 https://github.com/ruby/rbs/pull/2706 ## Updated workflow We can streamline the workflow by moving the core library RBS type definitions to `ruby/ruby` repository. - We will add a directory such as `sig` to `ruby/ruby` and store files like `string.rbs` there - Ruby's CI will run tests (`test-bundled-gems`) for the RBS type definitions in `ruby/ruby` repository. If your commit changes the core library methods/classes, please update the RBS files and tests too. - Ruby 4.1 will ship with the core type definitions, which will be installed with it. The rbs-gem will load the core library type definitions shipped with Ruby. With this workflow, when `test-bundled-gems` fails, you can fix the issue directly within your `ruby/ruby` work — without leaving the repository or coordinating a separate PR — which makes updating RBS much easier. *Note:* This workflow introduces a new step — *updating the RBS type definitions* — that wasn't previously required of Ruby committers. However, it replaces the existing workaround of skipping tests or coordinating a separate PR to `ruby/rbs` just to keep CI green. And unlike that workaround, updating the RBS definitions is itself a real improvement to Ruby. We believe this trade-off is acceptable. ## Implementation plan ### What we won't do 1. We will keep rbs-gem as a bundled gem. We won't make it a default gem, default library, or Ruby built-in. rbs-gem has a C extension, and changing from a bundled gem would require significantly more work for compilation. 2. We will keep the `ruby/rbs` repository for development of the library implementation. We want to release new versions of the gem more often than Ruby's release cycle. ### File layout in `ruby/ruby` repository - Type definitions will be stored under `sig/` (e.g., `sig/core/string.rbs`) - Type definition tests will be placed under `test/sig` - The bundled version of rbs-gem will be used to test against the `sig/` type definitions and `test/sig` tests Note that the directory names are tentative. Let me know if you have an idea what the names of the directories should be. ### Installation and distribution When Ruby is installed, the core and standard library RBS type definitions will be installed alongside it. The rbs-gem will reference these bundled definitions rather than maintaining its own copy. The RBS files will be installed under something like `"#{RbConfig::CONFIG["prefix"]}/sig"`, but the exact path is not decided yet. Suggestions are welcome! *Note:* We may also want an install-time option to skip installing the RBS type definitions, for example for minimal Ruby builds where they are not needed. #### Releasing new type definitions Currently, we can release a new version of rbs-gem to update the core type definition. After this migration, we need to wait for the next Ruby release to update type definition. I think this is okay, since the core type definition is pretty stable today. ### Testing RBS type definition tests will run as part of `make test-all` in `ruby/ruby`, rather than only through `test-bundled-gems`. This ensures type definitions are validated during the standard Ruby development workflow. Note that the RBS test suite currently takes 2–3 minutes in CI, so we need to decide which development tasks should include full testing. ### Other notes - Core RBS definitions contain documentation copied from RDoc, which needs to be updated before each release. For now, @soutaro plans to do this manually. - Ruby 4.0 and earlier releases do not include RBS type definitions, so the rbs-gem releases must continue to bundle them. @soutaro will copy the type definitions from `ruby/ruby` to `ruby/rbs` at each rbs-gem release. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:124888] [Ruby Bug#21927] Prism: misleading error message for forwarding in lambda argument
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21927 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21927: Prism: misleading error message for forwarding in lambda argument https://bugs.ruby-lang.org/issues/21927 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: prism * ruby -v: d256629bf9 * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Even in a forwarding method: ```console $ ruby --parser=prism -e 'def m(...) ->(...){}; end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m(...) ->(...){}; end | ^~~ unexpected ... when the parent method is not forwarding ``` This message is proper for method arguments: ```console $ ruby --parser=prism -e 'def m() p(...); end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m() p(...); end | ^~~ unexpected ... when the parent method is not forwarding ``` The message from parse.y is different; "unexpected ... in lambda argument": ```console $ ruby --parser=parse.y -e 'def m(...) ->(...){}; end' -e:1: unexpected ... in lambda argument def m(...) ->(...){}; end ruby: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124885] [Ruby Bug#21925] Prism misparses standalone "in" pattern matching in "case/in"
by knu (Akinori MUSHA) 07 Jun '26

07 Jun '26

Issue #21925 has been reported by knu (Akinori MUSHA). ---------------------------------------- Bug #21925: Prism misparses standalone "in" pattern matching in "case/in" https://bugs.ruby-lang.org/issues/21925 * Author: knu (Akinori MUSHA) * Status: Open * Target version: 4.1 * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Prism misparses standalone `in` pattern matching in `case/in` when the left-hand side is a method call with a dot receiver ## Summary When a standalone `expr in pattern` one-line pattern match appears inside a `case/in` branch, and `expr` is a method call with a dot receiver (for example, `obj.method`), Prism incorrectly parses `in pattern` as a new branch of the outer `case/in` instead of treating it as a `MatchPredicateNode`. The parse.y parser handles this case correctly. ## Reproduction ``` $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] ``` It also reproduces on Ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25]. ### Minimal script ```ruby x = "x" case x in Integer nil in String p :before x.itself in String p :after end ``` ### Command output ``` $ ruby -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before $ ruby --parser=parse.y -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before :after ``` ### Expected behavior (parse.y) Both `:before` and `:after` are printed. `x.itself in String` is parsed as a standalone pattern match (predicate) inside the `in String` branch. ### Actual behavior (Prism) Only `:before` is printed; `p :after` is never executed. ## Analysis Prism splits `x.itself in String` at the `in` keyword, treating `x.itself` as the last statement of the `in String` branch and `in String` as a third branch of the outer `case/in`. The following script shows how each parser interprets the `case/in` branches: ```ruby code = <<~RUBY x = "x" case x in Integer nil in String x.itself in String p :after end RUBY # Prism require "prism" ast = Prism.parse(code).value.statements.body[1] puts "Prism: conditions: #{ast.conditions.length}" ast.conditions.each_with_index do |c, i| pat = c.pattern name = pat.respond_to?(:name) ? pat.name : pat.class stmts = c.statements&.body&.map { |s| s.class.name.split("::").last } || [] puts " in[#{i}]: pattern=#{name}, body=#{stmts}" end # parse.y (Ripper) require "ripper" sexp = Ripper.sexp(code) case_node = sexp[1][1] def count_in_branches(node) return [] unless node.is_a?(Array) && node[0] == :in pattern_node = node[1] body = node[2] || [] name = pattern_node.is_a?(Array) && pattern_node[1].is_a?(Array) ? pattern_node[1][1] : pattern_node[1] stmts = body.map { |s| s[0].to_s } [{ pattern: name, body: stmts }] + count_in_branches(node[3]) end branches = count_in_branches(case_node[2]) puts "\nparse.y (Ripper): conditions: #{branches.length}" branches.each_with_index do |b, i| puts " in[#{i}]: pattern=#{b[:pattern]}, body=#{b[:body]}" end ``` Output (run with `ruby --parser=parse.y` so Ripper uses parse.y): ``` Prism: conditions: 3 in[0]: pattern=Integer, body=["NilNode"] in[1]: pattern=String, body=["CallNode"] in[2]: pattern=String, body=["CallNode"] parse.y (Ripper): conditions: 2 in[0]: pattern=Integer, body=["var_ref"] in[1]: pattern=String, body=["case", "command"] ``` Prism reports 3 branches, while parse.y reports 2. In the parse.y result, `in[1]` correctly contains both the inner expression (`x.itself in String` parsed as a standalone pattern match) and the `command` (`p :after`). In the Prism result, `x.itself` becomes the sole body of `in[1]`, and `in String` is misinterpreted as a new `in[2]` branch of the outer `case`. ## Consideration From experimentation, the issue appears to be triggered only when all of the following are true: 1. The outer `case/in` has at least two `in` branches before the affected branch. 2. The standalone `in` expression uses a dot-receiver method call as its left-hand side, such as `obj.method in Pattern`. Conditions where this behavior is not observed: - If the expression is a receiver-less call, such as `f(x) in Pattern`, the parser keeps it as a standalone pattern match. - If the receiver expression is parenthesized, such as `(obj.method) in Pattern`, the parser keeps it as a standalone pattern match. - If you assign first, such as `y = obj.method; y in Pattern`, the parser keeps it as a standalone pattern match. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:123731] [Ruby Bug#21674] Possible regression in return case in statement
by jandudulski (Jan Dudulski) 07 Jun '26

07 Jun '26

Issue #21674 has been reported by jandudulski (Jan Dudulski). ---------------------------------------- Bug #21674: Possible regression in return case in statement https://bugs.ruby-lang.org/issues/21674 * Author: jandudulski (Jan Dudulski) * Status: Open * ruby -v: 3.4.6 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Suddenly my code started failing in Ruby 3.4.6 and 3.4.7. Shortest code example: ``` ruby args = [:increased] context = Data.define(:event).new(:decreased) case args in [event] context.event in ^event end ``` In Ruby prior to 3.4.6 in returns `false` (as expected) but in 3.4.6 and 3.4.7 it returns `:decreased`. `context.event in ^event` still returns `false`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124474] [Ruby Bug#21831] Prism doesn't count underscores in the fraction part of rational float
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21831 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21831: Prism doesn't count underscores in the fraction part of rational float https://bugs.ruby-lang.org/issues/21831 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Good. ```console $ ruby3.3 -e 'p 0.1_2r.to_f' 0.12 $ ruby3.4 --parser=parse.y -e 'p 0.1_2r.to_f' 0.12 ``` Wrong. ```console $ ruby3.4 -e 'p 0.1_2r.to_f' 0.012 ``` -- https://bugs.ruby-lang.org/

4 3