Project

General

Profile

Bug #17032

BigDecimal's `to_d` behaves inconsistent compared to `to_f`

Added by TiloS (Tilo S) 2 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:99170]

Description

I would expect to_f and to_d to behave identically. Specifically, nil.to_d should behave like nil.to_f.

require 'bigdecimal'
require 'bigdecimal/util'
nil.to_f # => 0.0
nil.to_d # >> NoMethodError (undefined method `to_d' for nil:NilClass)

Users should not have to resort to this:

nil.to_f.to_d #  => 0.0
#1

Updated by sawa (Tsuyoshi Sawada) 2 months ago

  • Description updated (diff)
  • Subject changed from BigDecimal .to_d is behaving inconsistent compared to .to_f to `BigDecimal#to_d` behaves inconsistent compared to `#to_f`
#2

Updated by sawa (Tsuyoshi Sawada) 2 months ago

  • Subject changed from `BigDecimal#to_d` behaves inconsistent compared to `#to_f` to BigDecimal's `to_d` behaves inconsistent compared to `to_f`

Updated by jeremyevans0 (Jeremy Evans) 2 months ago

  • Status changed from Open to Closed

NilClass#to_d was added in Ruby 2.6. As it is not security-related (and seems more like a new feature than a bug fix), it will not be backported to Ruby 2.5, as that is in security maintenance mode.

Also available in: Atom PDF