Deprecating fromIntegral

[David Feuer]

 I would double down on the "no one has a great replacement yet".
There are several (potential, imaginary) replacements that may be
better in different contexts, depending on the precise programmer
intent. And then there's the question of how far we want to push
(relatives of) a function that doesn't really seem like entirely the
right idea. Completely aside from correctness issues, fromIntegral
also has efficiency trouble: it is completely dependent on
hand-written rewrite rules to avoid serious inefficiencies. A version
based on MultiParamTypeClasses would inspire much more confidence--but
it would require instances out the wazoo and surely lead to many
orphan instances. I suspect there are ways we can get better results
with fewer problems by designating several different intermediate
types and allowing Integral instances to place themselves in relation
to those. But that is ad hoc, and it requires one or more language
extensions, and I don't know if anyone's really played with it enough.
We shouldn't even be thinking about deprecation in the short term; we
should be working toward a medium-term replacement and a
very-long-term *potential* deprecation.

On Tue, Sep 26, 2017 at 12:41 PM, Edward Kmett <ekmett at gmail.com> wrote:
> 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
> not have a clear migration path for users at this point.
>
> The way I see it there are several gates between this proposal and any
> actual deprecation of fromIntegral.
>
> 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.
>
> 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.
>
> 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.
>
> 4. Then once it has been around in base long enough that users can migrate
> to it in accordance to the "3 Release Policy" then we could build consensus
> to perform a deprecation of the existing method.
>
> 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.
>
> 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.
>
> At least it seems to me that this is a large part of the resistance you are
> encountering here.
>
> -Edward
>
> On Tue, Sep 26, 2017 at 11:08 AM, Niklas Hambüchen <mail at nh2.me> wrote:
>>
>> Hey David,
>>
>> > I'm -1 on deprecating it, and +1 on adding additional conversion
>> > functions of various sorts: explicit widening, explicit narrowing, etc.
>>
>> What is your reasoning against deprecating it?
>>
>> That `fromIntegral` is a function that should be used in new code?
>> That emitting a warning for potentially wrong code is bad by itself?
>> Or that people have to change their code to be warning free?
>>
>> To me, a deprecation constitutes an organised, non-disruptive migration
>> from the old function to the new explicit functions, and I'd really like
>> to understand what people's reservations against it are.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>