[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055
Mon Apr 25 18:54:05 CEST 2022
On 2022/04/26 1:45, Loïc Hoguin wrote:
> On 25/04/2022 17:45, Austin Ziegler wrote:
>> That said, it took me a *long* time to understand `=:=` because it’s a
>> complex, compound sigil (not used _that_ frequently) that I’ve never
>> seen in any other language (and I know quite a few). To _me_, `^Value
>> -> …` is clearer than `NewValue when Value =:= NewValue`. But that’s me.
> It's one of the flaws that I wish could be fixed. I use =:= everywhere
> because it is more precise and it's the equivalent of == in many other
> languages. The mix and matching of integers and floats is Erlang trying
> to be too smart. Hopefully we can make == the same as =:= at some point
> and get rid of =:= and =/=. Is there even that much code that relies on
> Int == Float?
> I have the same opinion on pretty much all uses of the "number" type, I
> like to keep my integers away from my floats.
That's an interesting idea.
<<"foo">> is clearly not "foo", nor are other semantically equivalent
iolists, and you should have reform one to the other before expecting
them to compare equal (with either operator). A pretty strong argument
could be made for numerical comparisons working in the same "all
comparisons are strict" way, though this would be definitely considered
a wart of value semantics by some folks.
I think the ambiguity would creep in with "what to do with >, <, >=, and
=<?" I mean, true type order would imply something very different from
value comparison half the time, which is sorta kinda an ambiguity...
Anyway, this is an interesting idea. There are indeed *very* few places
that == is used where =:= wouldn't be appropriate as well.
More information about the erlang-questions