I love that question! The helpfulness of my answer will depend on your specific problem, but my most common use case is when I've used a custom type like this for ID values: type ID = ID String This made it so I wouldn't mix up IDs with other string types, but now it isn't ergonomic to use it with something like "Dict ID Project" or "Set ID". In the past, I've tried a few things: 1. Created a separate `Id.Set` module with an identical API, that handles wrapping/unwrapping this custom type before inserting in the set. (This preserves the type-safety and speed, but takes some work!) 2. Gave up some of the type safety, by storing ID as a String directly. This means using "type alias ID = String" instead, but allows me to use Dict and Set normally 3. Gave up on the speed, by using the "elm-community/assoc-set" package. This has the Set API, but uses a List under-the-hood. (Because Elm is only for web apps, there's rarely been something I've been storing that's been big enough to see a significant speedup) After working with Elm for a few years, the 3rd option seems to give me the most bang-for-my-buck. Converting custom types to/from comparable values is rarely worth it in my experience, but you might encounter scenarios where it is worthwhile!
@@HeyRyanHaskell Thank you very much, I seem to like option 3 the most so far. But the challenge itself goes to show that Elm could have benefited from some sort of typeclass support, at least something like Haskell's `deriving` for custom types.
So, how can I make a custom ADT comparable so to be able to use it with the Set?
I love that question! The helpfulness of my answer will depend on your specific problem, but my most common use case is when I've used a custom type like this for ID values:
type ID = ID String
This made it so I wouldn't mix up IDs with other string types, but now it isn't ergonomic to use it with something like "Dict ID Project" or "Set ID".
In the past, I've tried a few things:
1. Created a separate `Id.Set` module with an identical API, that handles wrapping/unwrapping this custom type before inserting in the set. (This preserves the type-safety and speed, but takes some work!)
2. Gave up some of the type safety, by storing ID as a String directly. This means using "type alias ID = String" instead, but allows me to use Dict and Set normally
3. Gave up on the speed, by using the "elm-community/assoc-set" package. This has the Set API, but uses a List under-the-hood. (Because Elm is only for web apps, there's rarely been something I've been storing that's been big enough to see a significant speedup)
After working with Elm for a few years, the 3rd option seems to give me the most bang-for-my-buck. Converting custom types to/from comparable values is rarely worth it in my experience, but you might encounter scenarios where it is worthwhile!
@@HeyRyanHaskell Thank you very much, I seem to like option 3 the most so far. But the challenge itself goes to show that Elm could have benefited from some sort of typeclass support, at least something like Haskell's `deriving` for custom types.