Hey Edward, I'm not going after Num here. What I care about is that base provide conversion functions with clear names that indicate what they do, so that the intent of the author becomes obvious. Currently we cram all number conversion functionality into `fromIntegral`, and offer no standard way for talking about code that has no intent to wrap. This code: fdReady ... (fromIntegral msecs) does not look obviously incorrect, but this code would: fdReady ... (fromIntegralWrap msecs) Of course it would be great if a name change came along with a set of type classes that make it compile-time-impossible to do an unintended cast, but in absence of one agreed way to do that, more functions with better names and appropriate error behaviour would already go a long way for avoiding bugs like this. To throw out some concrete examples, there could be: * maybeFromInteger / maybeFromIntegral - that return Nothing when the input doesn't fit * runtimeCheckedFromInteger / runtimeCheckedFromIntegral - `error` on Nothing * fromIntegerWrap / fromIntegralWrap - what the current functions do * fromInteger / fromIntegral - unchanged semantics, but emitting a deprecation warning Deprecation seems the best method by which we can systematically highlight all use sites where a replacement with a function of a better name, or missing edge case handling, should be inserted, without breaking code. Niklas