<div dir="auto">I'm -1 on deprecating it, and +1 on adding additional conversion functions of various sorts: explicit widening, explicit narrowing, etc.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sep 21, 2017 8:25 AM, "Niklas Hambüchen" <<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is not a joke.<br>
<br>
I just found a bug in base (<a href="https://ghc.haskell.org/trac/ghc/ticket/14262" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/14262</a>):<br>
<br>
  import System.IO<br>
  hWaitForInput stdin 4294968296<br>
<br>
This code should wait for 49.something days, but it waits for 1 second.<br>
<br>
It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt`<br>
(where CInt = Int32), causing an overflow.<br>
<br>
I argue that `fromIntegral` causes unnoticed data corruption without any<br>
warning, and thus are worse than partial functions.<br>
<br>
In this case, this data corruption occurs in the most fundamental code<br>
that we all use and have to rely upon (`base`).<br>
<br>
So I propose that we add a deprecation pragma to `fromIntegral`<br>
(however, keeping it forever, like Java does, as there's no benefit to<br>
removing it, we just want that people use safer functions over time),<br>
and instead provide a `safeFromIntegral` that can only widen ranges, and<br>
one or more `unsafeFromIntegral` or appropriately named functions that<br>
can error, wrap, return Maybe, or have whatever desired behaviour when<br>
the input value doesn't fit into the output type.<br>
<br>
For some inspiration, `foundation` provides ideas in that direction:<br>
<br>
<a href="http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html" rel="noreferrer" target="_blank">http://hackage.haskell.org/<wbr>package/basement-0.0.2/docs/<wbr>Basement-From.html</a><br>
<a href="http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralConv.html" rel="noreferrer" target="_blank">http://hackage.haskell.org/<wbr>package/basement-0.0.2/docs/<wbr>Basement-IntegralConv.html</a><br>
<br>
It is a bit funny how we argue that Haskell is good for high assurance<br>
programming, and we build all sorts of fancy constructs to eliminate<br>
more run-time errors, when in fact we do worse than C in detecting<br>
errors in the most basic types a computer can use, such as converting<br>
between 64-bit and 32-bit integers.<br>
<br>
Let's fix that.<br>
<br>
It avoids real problems in real production systems that are difficult to<br>
debug when they happen (who writes a unit test checking that a timeout<br>
of 50 days still works? This is the kind of stuff where you have to rely<br>
on -- very basic -- types).<br>
<br>
I'd like to probe support for such a change before doing any work on it.<br>
<br>
Niklas<br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>