Having it `error` in that case is probably not the best solution, given that the function was total before.

We can also probably leave out generating `Int32`, and have only `Int64` as before -- returning `Int32` "because the number fits" is a bit arbitrary (not that doing arbitrary isn't required for writing *random-format-to-random-format* converters, but if one case includes the other, we might be better off with less). If the user cares about making the Ints small, they can still do that check themselves.

It is difficult to say what a good way for your last case is: JSON, as a format, allows arbitrarily large numbers, BSON doesn't.
At the same time, most JSON *implementations* limit themselves to `Double` as does Javascript, so I suggest that we return everything that fits into `Int64` as `Int64` and everything else as a `Double` (thus accepting potential precision loss if the data comes from a JSON implementation that can actually do Bignums; I believe that before Aeson switched to Scientific, those cases would actually make the parse fail). In any case, we should clearly state this behaviour in the haddocks.

I think the only really clean solution that we should eventually implement is to let the final choice to the user, e.g. with:

```haskell
bsonifyValue :: AesonBsonOptions -> AESON.Value -> BSON.Value

data AesonBsonOptions = AesonBsonOptions
  { numberConversion :: Scientific -> BSON.Value -- ^ how to convert a JSON number to a BSON number [also explaining the problems with this here]
  }

defaultAesonBsonOptions = ...
```

That way, the user has to read what