*brushes dust off of topic* We are now a few months further, but I believe that a standardized method of comparing datatypes still is a relevant addition to the language.
What would be the best approach to go from here? Some possibilities: - More discussion here on the current implementation idea that OvermindDL1 and me came up with. Major unsolved 'problem' might be how to integrate it more with the rest of the Elixir language, as it is basically does something similar to protocols, but then for a *combination* of two datatypes (in no particular order, as comparison is symmetric (or in proper mathematical terms, converse)), which is similar but different from what already exists in the language. - Maybe ask the larger group of people on the Elixirforum about their opinions on this, although this might lead to bike-shedding <https://en.wikipedia.org/wiki/Law_of_triviality>. On Sunday, August 7, 2016 at 10:13:45 PM UTC+2, Michał Muskała wrote: > > Hello everybody, > > Today I’d like to address one of annoyances of working with elixir - > comparing structs. It’s a problem because of two reasons: > - it’s not widely known that the regular comparison operators do not work > correctly with structs > - there’s no standard way of providing custom comparison function. > This issue is especially apparent in couple libraries, most notably Ecto > (with calendar types), decimal and with the new standard calendar types. > > I propose adding a Kernel.compare/2 function with signature: > compare(term, term) :: :lt | :eq | :gt > > I would propose following properties of the function: > - inlined implementation for built-in types, only for both arguments of > the same type > - for structs the function calls the Comparable.compare/2 protocol > function > - implementation for structs are allowed to return value for two different > types when it makes sense > - the protocol is also implemented for built-in types > - the protocol does not fallback to Any > > I’m convinced this will allow for much easier experience when comparing > structs, even though the VM does not allow to extend the regular comparison > operators. > > Michał. > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/585be51c-8f20-48ae-b2b2-858e54a07744%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
