[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

[zxq9]

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.

-Craig