update signature | Money#nonzero? returns nil or BigDecimal

[jparker]

Updates the signature for Money#nonzero? to return T.nilable(BigDecimal) instead of T::Boolean. Money delegates #nonzero? to the underlying value, stored as a BigDecimal which returns either nil or self.

Type of Change

• Add RBI for a new gem
• Modify RBI for an existing gem
• Other:

Changes

• Gem name: shopify-money, bigdecimal
• Gem source:
  • https://github.com/Shopify/money/blob/bb637314aa797a8017cfd5e7990fcd8d751a62a9/lib/money/money.rb#L139
  • https://github.com/Shopify/money/blob/bb637314aa797a8017cfd5e7990fcd8d751a62a9/lib/money/money.rb#L14
  • https://github.com/ruby/bigdecimal/blob/d93b542015d03b4b20565f59830b20c4d45bf87b/ext/bigdecimal/bigdecimal.c#L1460-L1466
• Gem API doc: https://ruby-doc.org/3.4/gems/bigdecimal/BigDecimal.html#method-i-nonzero-3F
• Tapioca version: 0.16.11
• Sorbet version: 0.5.12358

irb(main):002> Money.new(0, 'USD').nonzero?.class
=> NilClass
irb(main):003> Money.new(1, 'USD').nonzero?.class
=> BigDecimal

[jparker]

I have signed the CLA!

[amomchilov]

Hey John!

I'm a bit torn on what to do here. T::Boolean is a more reasonable choice from an API design perspective, but T.nilable(BigDecimal) is more true to the actual runtime behaviour of the library at runtime. It's quite weird, especially that it returns the wrapped BigDecimal, not the self (Money).

This is also a breaking change to make: Sorbet.run

Can you please share an example use-case that uses the result value of this as a big decimal, rather than just using its truthiness/falsiness to treat is like a boolean?

[jparker]

Hey John!

I'm a bit torn on what to do here. T::Boolean is a more reasonable choice from an API design perspective, but T.nilable(BigDecimal) is more true to the actual runtime behaviour of the library at runtime. It's quite weird, especially that it returns the wrapped BigDecimal, not the self (Money).

This is also a breaking change to make: Sorbet.run

Can you please share an example use-case that uses the result value of this as a big decimal, rather than just using its truthiness/falsiness to treat is like a boolean?

To be honest, I can't. I generally only ever use this predicate in a context where returning a boolean makes the most logical sense. I only noticed the problem in practice because I had adapt a signature in some application code that could return the result of #nonzero? to accommodate the true return value.

Other Numeric classes implement similar behavior for #nonzero?, so the actual behavior is quirky but consistent. But I agree, a true boolean would be less surprising (at least to me) in most cases. That said, Money does differ from the Numeric classes in that it doesn't return self but returns @value. It kind of feels like Money should either actually return self for parity, or should implement the method directly with a true boolean return value instead of delegating it.

---

EDIT: Maybe an alternative is for Money itself to implement the method directly with a truly Boolean return value rather than delegating? There is one inconsistency in that it returns the underlying BigDecimal and not self.