Reconsider double.mul() and double.sub() implementations

[AnyhowStep]

Right now, double.mul() and double.sub() have number|null for the return type.

This only happens because of SQLite.

• 1e999 * 0e0 is null on SQLite.
• 1e999 - 1e999 is null on SQLite.

You can't even use Infinity in other databases; so, we don't get these problems.

It would be nice if we made mul()/sub() just return number.

In SQLite, this would be emulated with COALESCE(x * y, (SELECT SUM(9223372036854775807) FROM (SELECT NULL UNION ALL SELECT NULL)))

Or, throwIfNull(x * y)

[AnyhowStep]

Then, if we want multiplication-but-allow-null-return-type-for-nan, we can have a separate function double.mulWithNan() or some other such nonsense

[AnyhowStep]

Or maybe just not have mulWithNan for the unified library at all

[AnyhowStep]

It all boils down to what this library is really intended to do.

The number 1 concern is to have consistent behavior across all supported databases, as long as the unified library is used to build the queries and expressions.

Given databases A and B, we have the following scenarios,

• A and B have the function
  • Both have the same behavior
  • This is a no-brainer; add it to the unified library
  • Both have different behavior
  • This is the problem double.mul(), double.sub(), etc. have
  • Force A to have B's behaviour?
  • Force B to have A's behaviour?
  • Give both different names and emulate both?
  • Don't add it at all?
  • Would users usually expect the behavior of A or B?
• A has the function, B does not
  • It is easy to emulate in B with built-ins
  • Emulate it
  • It is hard to emulate in B with built-ins
  • Might be worth it to emulate
  • It is impossible to emulate in B with built-ins
  • Do we have other "easy" mechanisms of emulation? (User-defined functions in SQLite)
  • Don't bother if there isn't
• Both do not have the function
  • It is useful (like throwIfNull())
  • Add it if it can be emulated
  • It is not useful
  • Don't bother