Deprecating fromIntegral

[Herbert Valerio Riedel]

On 2017-09-21 at 14:24:14 +0200, Niklas Hambüchen wrote:

[...]

> I argue that `fromIntegral` causes unnoticed data corruption without any
> warning, and thus are worse than partial functions.

[...]

> So I propose that we add a deprecation pragma to `fromIntegral`

Tbh, given how ubiquitous the use of `fromIntegral` is throughout the
Haskell ecosystem, having 'fromIntegral' suddely emit warnings when
`-Wall` is active is not realistic IMHO.

You'd have to introduce a separate (opt-in) category of WARNING pragmas
for that (something some of us would also like to see for the category
of partial functions) which isn't implied by -Wall.

> (however, keeping it forever, like Java does, as there's no benefit to
> removing it, we just want that people use safer functions over time),
> and instead provide a `safeFromIntegral` that can only widen ranges, and
> one or more `unsafeFromIntegral` or appropriately named functions that
> can error, wrap, return Maybe, or have whatever desired behaviour when
> the input value doesn't fit into the output type.

[...]

> It avoids real problems in real production systems that are difficult to
> debug when they happen (who writes a unit test checking that a timeout
> of 50 days still works? This is the kind of stuff where you have to rely
> on -- very basic -- types).

I ran into this very problem early on. I'll use the opportunity to
shamelessly plug an older package of mine probably only few know about
which solved this very problem in mission critical systems for me while
avoiding to have to enumerate O(n^2) transitions explicitly:

  http://hackage.haskell.org/package/int-cast-0.1.2.0/docs/Data-IntCast.html

But it isn't plain Haskell 2010...

Another related package which may be useful in this context is
http://hackage.haskell.org/package/safeint which helps avoid silent
integer overflows during arithemtic operations.