I would expect BigDecimal#divmod to return type [Int, BigDecimal] (like Integer#divmod, Float#divmod)

[michaelglass]

Integer#divmod returns type [Integer, Integer]
Float#divmod returns type [Integer, Float]
BigDecimal#divmod returns type [BigDecimal, BigDecimal]

Which feels surprising.

1.divmod(2)
=> [0, 1]
(1.0).divmod(2)
=> [0, 1.0]
BigDecimal(1).divmod(2)
=> [0.0, 0.1e1]

(thank you BigDecimal maintainers, you are wonderful)

[tompng]

Float(limited precision float) and Integer(arbitary precision integer) are incompatible, but BigDecimal can represent both integers and decimals.
So BigDecimal#divmod => [BigDecimal, BigDecimal] can be considered a design decision.

But considering the fact that BigDecimal#div(x) and BigDecimal#round(negative_number) returns Integer instead of BigDecmal as a design, I think divmod returning [Integer, BigDecimal] seems more consistent.

# BigDecimal can select returning integer as BigDecimal
# but selected to return Integer as a design
BigDecimal('123.456').div(3) #=> 41, not 0.41e2
BigDecimal('123.456').round(-2) #=> 120, not 0.12e3

[x.div(y), x.modulo(y)] #=> [Integer, BigDecimal]
x.divmod(y) #=> [Integer, BigDecimal] is better than [BigDecimal, BigDecimal]