Deprecating fromIntegral

[Niklas Hambüchen]

Hey Edward and David,

Edward Kmett wrote:
> 1. [...] 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

I agree, as stated before, deprecation without replacement makes no sense.

It's the point of this thread to

* determine what replacements people would consider good
* find if, assuming we have found good replacements, there would be
still other obstacles (such as the ones you mention below)

So far, it seems that there is broad support for more appropriately
named functions while a type-based approach is controversial; I consider
this a useful outcome of this thread, and think that this is also the
approach that can provide the easiest migration path.

> 4. Then once it has been around in base long enough that users can
> migrate to it in accordance to the "3 Release Policy"
> <https://prime.haskell.org/wiki/Libraries/3-Release-Policy> then we
> could build consensus to perform a deprecation of the existing method.

Waiting for 3 releases seems fine.
But I don't see why consensus could only be built after that.

It seems that if consensus exists already at a time before, deprecation
can be planned ahead of time.
The linked page contains examples of that, e.g. the deprecation of
`Monad.fail` that is already scheduled for 8.6.

> 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.

That's a good point; are there reasons why we should not use
deprecations for both patterns ("hey you might want to do something
else" and "this is your last notice")?

If yes, maybe we should add means to support the first pattern.

That goes along with another thought:

The fact that the 3-release-policy says that warnings cannot be added
even for -Wall means that currently there is no flag one can use to get
all of the "latest" warnings GHC can produce to make code safer and more
correct.
Perhaps a -Wextra equivalent is needed?

(Personally I find it unfortunate to have a flag called -Wall not emit
all warnings, or it complaining about benign topics like unused imports
while letting data corruption pass unnoticed for long, or an
off-by-default flag intended to produce as many warnings as possible to
be restricted by a backwards compatibility policy, but C compilers at
least make these a common occurrence.)

> At least it seems to me that this is a large part of the resistance you
> are encountering here.

Thanks for the insights, very appreciated.