NaN is not an int.
There's no type except float that captures the values returned by parseInt.
If moved to int, the function should be wrapped and adapted to e.g. return an optional, and not be zero-cost. Not sure if there's much value in doing that.

The parseInt and parseFloat functions are really quite bad, and I don't think they should even be used internally in Int.fromString and Float.fromString either. I've been thinking of opening an issue to discuss alternatives to it, but there aren't really any great alternatives either, so it requires a thorough exploration of the trade-offs.

Returning an option seems to be a good choice. Int.fromString already returns an option.

Some options:

• Since parseInt and parseIntWithRadix accepts a generic we can remove Int.fromString
• Rename Int.fromString to Int.parseInt (with optional ~radix parameter) and keep only one function. The current function Int.fromString doesn't make sense if we have parseInt and parseIntWithRadix

I think the parseInt and parseIntWithRadix functions should not accept a generic

I've been thinking of opening an issue to discuss alternatives to it, but there aren't really any great alternatives either, so it requires a thorough exploration of the trade-offs.

See #86 for said issue.