Core: API Suggestion - custom compare-functions for dict/set

Created on 6 Mar 2018 · 6Comments · Source: elm/core

I've been reading through a lot of the discussion of comparison in Elm; My particular problem with comparison is that I often want to use unions as keys in sets & dicts.

An approach I haven't read about so far would be to change the signature of the functions that construct Sets and Dicts. For example:

Dict.empty : ( k → k → Basics.Order ) → Dict k v

Simply provide a comparison instead of using Basics.compare. There's a lot of flexibility to this, and you can have the old behavior by simply passing Basics.compare as the first argument to these constructing functions.

The API changes I'm suggesting ~required~ to do this are obvious: all constructing functions for the collections would need to take a comparison function as it's first input, and quite a few functions would have to exchange their comparable input signatures for a type variable

Even if the current signatures are considered more friendly, one could make the implementation detail of having the Dict / Set carry the comparison function of the before-mentioned signature and then simply expose, for example, empty or singleton with Basics.compare partially applied.

Source

opvasger

All 6 comments

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

process-bot on 6 Mar 2018

❤1

I do not want to track feature requests in issues for a couple reasons:

Rather than focusing on things that could be better, I am prioritizing things that cannot be done. In this case, the workaround is creating new definitions and type aliases. So this can be done, but could be better.
Feedback online is not representative of Elm users. The fraction of people using Elm who will never give feedback through a GitHub issue is certainly higher than 90%. So like in normal products, doing user studies is a better way to gather feedback.
If a feature request is "alright" it can sit around for a long time, cluttering up all the other issues that are related to bugs. Having it open or closed does not change whether we can look back at it though.
So for those reasons, I am closing this. We can still refer back to it at an appropriate time.

Based on reading you write this in another issue, I will close this issue, and find a more suitable place to post. I apologize for the noise

opvasger on 7 Mar 2018

No need to apologize! I have a rather unconventional view on these sorts of things, and it seems like different assumptions are literally built in to GitHub, so it makes sense that people are surprised by the preferences here. I'll be working on communicating these things better in the future though!