Deprecating fromIntegral

[Evan Laforge]

On Thu, Sep 21, 2017 at 8:57 AM, Niklas Hambüchen <mail at nh2.me> wrote:
> Deprecation-marking does not break any code, it is the softest way to
> make a transition. The Java community has this figured out: Deprecations
> are common, they don't break the build, they don't change behaviour,
> downstream libraries adapt quickly to them, and the whole ecosystem can
> advance to a more solid foundation gracefully.

As I remember it, where I worked there was a distinction between
deprecations and warnings.  Deprecations had no visible output outside
the documentation, unless you used an IDE and turned on the
dotted-underline feature, while warnings would be printed during the
compile.  You were not supposed to deprecate anything without a
clearly documented "do this instead" but you didn't need a plan to fix
all the callers.  But to emit a warning, a bounded-time plan was
required, which probably involved a global fix via automatic
refactoring.

Otherwise, warnings accumulate, and once they get past a certain
amount everyone ignores all of them equally, which is a loss as we
lose the high value ones too.  Most of them come out of compiling
stuff you don't own and don't understand and don't have time to go
fix.

If I were to suddenly get 10,000 lines of warnings... well, if it can
be fixed with a global search and replace then it's ok if they only
indicate a few real problems.  But if the fix is more complicated and
requires individually looking at each place, then they had better have
a pretty good positive rate.  Otherwise I wind up turning off the
warning and it might as well not exist.

You could say there's a place for low value lint type warnings which
you could turn on just for hlint style suggestions, but it needs to be
integrated with the source control so it can warn only about the bits
that you just changed.  Otherwise no one can repeatedly comb through
the 10,000 suggestions in case some have been added, so in practice it
just stays off forever.

Also in my experience the bit about "downstream libraries adapt
quickly to them" is wildly optimistic :)