Definitely the big reason from my perspective to make more things
comparable is to allow their use with dictionaries and sets. For that
usage, the comparison could even be compiler dependent (or even execution
dependent) but I'm sure that someone would build code that depended on
properties of
I just realized that the sortBy function already allows you to sort a list
by any sort criterion of your choice. Which removes some of my concerns in
the previous post.
On Friday, August 4, 2017 at 12:06:53 PM UTC-4, Ambrose Laing wrote:
>
> It seems like a minor detail that may come as a
It seems like a minor detail that may come as a matter of course, but I'd
like to request that Bool's should also be comparable. If Bools are not
comparable but you embed a Bool inside a tuple or a List or a Record, that
makes the larger type also not comparable. Unless you decide to ignore
>
> Having a deriving-esque way to generate encoders and decoders
> automagically would be great, and would go a long way in solving the
> hassle. (2) would also make my life easier.
> The problem I see with both deriving-esque auto coders (DEAC, patent
> pending) and comparable union types,
>
> The problem I see with both deriving-esque auto coders (DEAC, patent
> pending) and comparable union types, is the difficulty of implementation.
> DEAC's seem like an advanced language feature that will take a while to get
> into the language.
>
Having talked to Evan about it, it seems
>
> Also worth noting that (2) is already slated to be fixed directly. It's a
> lower priority than other things in the hopper right now, but it'd probably
> still be higher priority than adding an enum feature.
>
This is fantastic news!
--
You received this message because you are
Regarding (2), I was not aware of this. Cool =)
Having a deriving-esque way to generate encoders and decoders automagically
would be great, and would go a long way in solving the hassle. (2) would
also make my life easier.
The problem I see with both deriving-esque auto coders (DEAC, patent
>
> However, strings and numbers still need to be used in production apps for
> several reasons:
> 1) Union Types is not supported in Json, so one needs to convert to/from
> strings or numbers for communicating with other systems.
> 2) Union Types are not comparable, and so cannot be used as
