<div dir="ltr">Thanks for the input!<div><br></div><div>> <span style="font-size:12.8px">I think we need a release _without_ DEPRECATION </span><span style="font-size:12.8px">first...</span><span style="font-size:12.8px">though this might be </span><span style="font-size:12.8px">changing</span><br><div><br></div><div>Either works for me. Personally I'd like it to be removed eventually but I anticipate the timeline for that will be long, in which case having a minor release that doesn't deprecate it to start doesn't seem like it would cause any harm. Then we can wait until the PVP decision is worked out.</div><div><br></div><div>> <span style="font-size:12.8px">until/unless we get </span><span style="font-size:12.8px">Backpack support on containers and unordered-containers</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Yeah, this would make it a requirement that they share the same name, in the meantime its unfortunate that they don't have the same name. Obviously an extreme, but imagine if "fmap" was called something different by every functor instance :P Since the migration for users is very straightforward I'd argue the cost is pretty low to increase consistency.</span></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 23, 2018 at 6:59 PM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 24 January 2018 at 13:14, Matt Renaud <<a href="mailto:matt@m-renaud.com">matt@m-renaud.com</a>> wrote:<br>
> What<br>
> ====<br>
><br>
> Rename unordered-container's Data.HashMap.lookupDefault to findWithDefault.<br>
><br>
> findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v<br>
><br>
> Note: There are no functionality changes, this is purely a rename.<br>
><br>
><br>
> Why<br>
> ===<br>
><br>
> This aligns the Data.HashMap API with containers' Data.Map.findWithDefault.<br>
><br>
> Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a<br>
><br>
> The map APIs provided by the two packages are almost drop in replacement<br>
> compatible if you aren't using any of the implementation specific functions<br>
> (like ordering based functions from Data.Map), this change brings us one<br>
> step closer.<br>
><br>
> API consistency reduces the cognitive overhead when learning a new package.<br>
> Having to learn different function names for the same functionality<br>
> depending on which "map" implementation you're using is a poor developer<br>
> experience.<br>
><br>
> We chose the containers' name findWithDefault over unordered-containers'<br>
> lookupDefault for two reasons:<br>
><br>
> Existing lookupX functions returns a Maybe value, while findX functions<br>
> return a non-wrapped value.<br>
> The containers package ships with GHC and is a "core" package.<br>
><br>
><br>
> Pros:<br>
> -----<br>
><br>
> - Consistent API between different "map" implementations (Data.Map,<br>
> Data.IntMap, Data.HashMap). This makes switching implementations an import<br>
> change.<br>
> - Naming matches other similar functions (lookupX return Maybe-wrapped<br>
> values)<br>
><br>
> Cons:<br>
> -----<br>
><br>
> - API change requires users to update their code<br>
>   + unordered-containers has A LOT of users: 358815 total (13325 in the last<br>
> 30 days)<br>
><br>
><br>
> How<br>
> ===<br>
><br>
> <a href="https://github.com/tibbe/unordered-containers/pull/176/commits/152f8818ee13dacb370e49b904edc4c1a4c8f87b" rel="noreferrer" target="_blank">https://github.com/tibbe/<wbr>unordered-containers/pull/176/<wbr>commits/<wbr>152f8818ee13dacb370e49b904edc4<wbr>c1a4c8f87b</a><br>
><br>
> Code Changes:<br>
> -------------<br>
><br>
> - Rename the function in Data.HashMap.Base (and expose it from Strict and<br>
> Lazy modules)<br>
> - Make lookupDefault an INLINE alias of findWithDefault<br>
> - Add DEPRECATION notice to lookupDefault<br>
> - Bump unordered-containers version to 0.2.9.0<br>
><br>
><br>
> Migration - Option 1:<br>
> ---------------------<br>
><br>
> - Announce on Haskell communication channels (haskell-cafe@,<br>
> haskell-community@, #haskell on Twitter, Reddit thread, etc.)<br>
> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated<br>
> function<br>
> - Code can be updated by find and replace: s/lookupDefault/<wbr>findWithDefault/<br>
> - lookupDefault with deprecation notice remains for 1 year (subject to<br>
> change)<br>
> - after 1 year the lookupDefault function is removed, unordered-containers<br>
> version bumped to 0.3.0.0 (major version bump due to breaking change)<br>
><br>
> Migration - Option 2:<br>
> ---------------------<br>
><br>
> - Announce on Haskell communication channels (haskell-cafe@,<br>
> haskell-community@, #haskell on Twitter, Reddit thread, etc.)<br>
> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated<br>
> function<br>
> - Code can be updated by find and replace: s/lookupDefault/<wbr>findWithDefault/<br>
> - lookupDefault function is never removed<br>
><br>
><br>
> Discussion:<br>
> ===========<br>
><br>
> I would like to get some comments on this proposal. In particular:<br>
> - Is the small API churn worth the increase in consistency?<br>
> - Should migration option 1 (completely remove the old function) or 2 (keep<br>
> old function indefinitely) be taken? We can punt on this and go with option<br>
> 2 to start and revisit later if desired.<br>
><br>
> I hope a decision about the proposal can be reached by 2018-02-09. Thanks!<br>
<br>
</div></div>I prefer Option 1, but I think we need a release _without_ DEPRECATION<br>
first, and then it can be added to lookupDefault (which currently<br>
requires a major version bump per the PVP, though this might be<br>
changing: <a href="https://github.com/haskell/pvp/issues/12" rel="noreferrer" target="_blank">https://github.com/haskell/<wbr>pvp/issues/12</a> )<br>
<br>
Whether this is worth it though is another story; until/unless we get<br>
Backpack support on containers and unordered-containers (which also<br>
requires adding a lot more functionality to the latter last I checked)<br>
I think it's OK that they use different names.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" rel="noreferrer" target="_blank">http://IvanMiljenovic.<wbr>wordpress.com</a><br>
</font></span></blockquote></div><br></div>