I know you are quoting the docs, but Gleam absolutely throws implicit exceptions, for exactly the same reason why it returns 0 when dividing: the Erlang/VM does not support Infinity/NaN, which means floating point operations can also overflow/underflow. For example, any division with a subnormal will raise:

    1.0 /. 5.0e-324

Or addition between really large floats:

    1.0e308 +. 1.0e308

In fact, even the `float.divide` function, which is meant to be safe, will raise:

    float.divide(1.0, 5.0e-324)

In other words, most functions that returns floats have an unmapped codomain and because of how floats work, and it is not simply a matter of checking if one of the inputs is equal to 0.0.

If Gleam wants to be consistent with division, all float operations would have to return a `Result` type (which I assume would have a direct impact in both performance and user convenience). Plus `let assert` provides a hatch for any function to raise too, and that includes matching on unmapped floats:

    let assert <<a:float>> = <<0x7FF0000000000000:64>>