Do we really need the strict comparison operator "===" in Elixir?

[Anton Fagerberg]

When I started learning Elixir a little while back, I read the getting started guide and I really liked how concise and clean the language was - but there where two details which has bugged me a bit ever since. One of them is the strict comparison operator (the other one is the && vs and which is another discussion).

I feel that === is unnecessary in Elixir. When I think of languages, most of them get along fine without it, and this might be just me, but having an === operator often indicates that the "normal" == operator has a lot of caveats and tricky behaviors (like our notorious friend JavaScript). In Elixir on the other hand, the == operator works as one would want. You can't do things like "1" == 1, so as far as I can tell, the only use for the === operator is to avoid comparing floats with integers. To have an operator for only this special case feels a bit unnecessary. I've never felt like I missed === in other languages which doesn't have it (and this could of course be achieved with the combination of == and is_integer/1 or is_float/1 in Elixir if it wasn't present).

Is it because of the Erlang heritage with =:= and =/= which lead to the inclusion of both == and === in Elixir because of some kind of compatibility? It would be interesting to hear your thoughts around this little detail!

[Alexei Sholik]

I haven't once needed to use == with the intent of comparing numbers of different types. In other words, the semantics of === is what I need 100% of the time. And I think that using == to compare numbers of different types yields dodgy code that begs for refactoring to make the intent of the author clearer.

It seems that there wasn't much thought put into the necessity of having both == and === when they were brought over from Erlang. Since then, nobody has questioned the usefulness of having both in the language, and so it has become a language quirk that just naturally ended up in version 1.0.

If Elixir had only == (with the semantics of the current ===), in the rare case when one needed to compare numbers of different types, they would have to come up with something like this:

  def eq(a, b) when is_number(a) and is_number(b), do: a * 1.0 == b * 1.0

And that would be great, IMO, because nobody in their right mind would think that code is fine. :)

--
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 elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Meadows-Jönsson]

Both operators are actually useful (which one of them should be the short == is another question). We need the non-strict one because it’s consistent with < and >.

Imagine if we only had this:

1.0 > 1 #=> false
1.0 < 1 #=> false
1.0 === 1 #=> false

It’s not hard to imagine that this behavior could cause issues in a dictionary that relies on the term order. So we need the non-strict == to handle these scenarios. Using Alexei’s proposed eq/2 would be not be satisfactory for a dictionary that should handle all terms in the language.

And on the other hand === is needed for every dictionary type relying on strict equality where dict[1] != dict[1.0].

​

--

Eric Meadows-Jönsson