Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault

[Matt Renaud]

> Doesn't quickly adding a deprecation warning break building any of those
1000+ packages with -Werror?

It appears that https://github.com/haskell/pvp/issues/12 is close to being
resolved[1], and as hvr mentioned Hackage already prevents packages with
-Werror from being uploaded, so this shouldn't be an issue for packages
already uploaded. But yes, if someone is using unordered-containers and
building locally with -Werror then the build would fail.

That being said, if the plan is to deprecate it then I don't think there's
a better way than marking it DEPRECATED. We could go with a "soft"
deprecation--remove function comments and replace with "This function is
deprecated, use findWithDefault" and make some announcements--but I doubt
many people would act on that so it would just be kicking the can down the
road.

> I'd support adding the new function, but am very reluctant to force any
quick changes.

Glad to hear! It would be nice if there was a way of getting information
about how often this particular function was used so we could get a better
estimate of how many packages would truly be affected. And I completely
agreed that we should do everything we can to not break people's builds,
but hopefully not at the expense of improving APIs.

[1] https://github.com/haskell/pvp/pull/18

On Wed, Jan 24, 2018 at 3:25 PM, <amindfv at gmail.com> wrote:

> Doesn't quickly adding a deprecation warning break building any of those
> 1000+ packages with -Werror?
>
> I'd support adding the new function, but am very reluctant to force any
> quick changes.
>
> Tom
>
>
> > El 24 ene 2018, a las 09:25, Andreas Abel <andreas.abel at ifi.lmu.de>
> escribió:
> >
> > > I'd say 1 year is too short. There is no need to remove the function
> > > quickly. I'd vote for adding a deprecation warning soon, but then keep
> > > the function until the next larger API overhaul or say, for five years
> > > or a decade.
> >
> > +1.
> >
> > Yes.
> >
> >> On 24.01.2018 08:11, Henning Thielemann wrote:
> >>> On Tue, 23 Jan 2018, Matt Renaud wrote:
> >>> Cons:
> >>> -----
> >>>
> >>> - API change requires users to update their code
> >>>   + unordered-containers has A LOT of users: 358815 total (13325 in
> the last 30 days)
> >> A better measure are certainly the reverse package dependencies:
> >>    https://www.stackage.org/package/unordered-containers
> >> There are almost 1000 packages that import unordered-containers, still
> quite a lot!
> >>> Migration - Option 1:
> >>> ---------------------
> >>>
> >>> - Announce on Haskell communication channels (haskell-cafe@,
> haskell-community@, #haskell on Twitter, Reddit
> >>> thread, etc.)
> >>> - Users of unordered-containers >= 0.2.9.0 receive warning about
> deprecated function
> >>> - Code can be updated by find and replace: s/lookupDefault/
> findWithDefault/
> >>> - lookupDefault with deprecation notice remains for 1 year (subject to
> change)
> >>> - after 1 year the lookupDefault function is removed,
> unordered-containers version bumped to 0.3.0.0 (major
> >>> version bump due to breaking change)
> >> I'd say 1 year is too short. There is no need to remove the function
> quickly. I'd vote for adding a deprecation warning soon, but then keep the
> function until the next larger API overhaul or say, for five years or a
> decade.
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> >
> > --
> > Andreas Abel  <><      Du bist der geliebte Mensch.
> >
> > Department of Computer Science and Engineering
> > Chalmers and Gothenburg University, Sweden
> >
> > andreas.abel at gu.se
> > http://www.cse.chalmers.se/~abela/
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180124/76bafe73/attachment-0001.html>