Project

General

Profile

Actions

Bug #17032

closed

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

Added by TiloS (Tilo S) over 3 years ago. Updated over 3 years ago.

Status:
Closed
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
Actions #1

Updated by sawa (Tsuyoshi Sawada) over 3 years ago

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

Updated by sawa (Tsuyoshi Sawada) over 3 years 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) over 3 years 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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0