Deprecating fromIntegral

Niklas Hamb├╝chen mail at nh2.me
Thu Sep 21 17:26:45 UTC 2017


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


More information about the Libraries mailing list