<div dir="ltr">To me deprecation is a big deal, especially for something exported from Prelude and which has been around since before Haskell 98, when we simply do <i>not</i> have a clear migration path for users at this point.<div><br></div><div>The way I see it there are several gates between this proposal and any actual deprecation of <font face="monospace, monospace">fromIntegral</font>.</div><div><br></div><div><div>1. At present there is no story here for how users change their code to address the deprecation. They'd just get to stare at a -Wall full of warnings and have no migration path.</div><div><br></div><div>2. To start a deprecation process here I'd at the very least want to have a replacement that a decent cross-section of folks have been able to agree is an improvement. This could be packaged up independently, could be selected from among other solutions that folks have already packaged up, etc. I don't care where it comes from so long as you can get enough people agree that it is the right solution.</div><div><br></div><div>3. Build consensus to move it into base. That way to address any eventual deprecation there can be a road map that doesn't incur new dependencies for users.</div><div><br></div><div>4. Then once it has been around in base long enough that users can migrate to it in accordance to the <a href="https://prime.haskell.org/wiki/Libraries/3-Release-Policy">"3 Release Policy"</a> then we could build consensus to perform a deprecation of the existing method.</div><div><br></div><div>This is unfortunately a relatively slow and tedious process, but the alternative is a Prelude-affecting change that breaks our release policies and all of the books being made with no real notice. </div><div><br></div><div>The current usage pattern and policies we have around deprecations isn't to use them as the first notice of "hey you might want to do something else", but rather to catch folks on the tail end right before something gets removed and long after what the user should do to in response has been carefully documented and considered.</div></div><div><br></div><div>At least it seems to me that this is a large part of the resistance you are encountering here.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 26, 2017 at 11:08 AM, Niklas Hambüchen <span dir="ltr"><<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey David,<br>
<span class=""><br>
> I'm -1 on deprecating it, and +1 on adding additional conversion<br>
> functions of various sorts: explicit widening, explicit narrowing, etc.<br>
<br>
</span>What is your reasoning against deprecating it?<br>
<br>
That `fromIntegral` is a function that should be used in new code?<br>
That emitting a warning for potentially wrong code is bad by itself?<br>
Or that people have to change their code to be warning free?<br>
<br>
To me, a deprecation constitutes an organised, non-disruptive migration<br>
from the old function to the new explicit functions, and I'd really like<br>
to understand what people's reservations against it are.<br>
<div class="HOEnZb"><div class="h5">______________________________<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>
</div></div></blockquote></div><br></div>