Array hashing breaks equality on 0.7

[chethega]

struct totally_not_five end

Base.isequal(::totally_not_five, x)=isequal(5,x);
Base.isequal(x, ::totally_not_five)=isequal(5,x);
Base.isequal(::totally_not_five, ::totally_not_five)=true;
Base.hash(::totally_not_five, h::UInt64)=hash(5, h);
import Base.==
==(::totally_not_five, x)= (5==x);
==(x,::totally_not_five)= (5==x);
==(::totally_not_five,::totally_not_five)=true;

n5=totally_not_five();

############
versioninfo()
#Julia Version 0.7.0-DEV.3961
#Commit 12964e839e* (2018-02-13 10:42 UTC)

5== n5 #true
isequal([4,n5,6], [4,5,6]) #true 
isequal(hash([4,n5,6]), hash([4,5,6])) # false
isequal(hash([n5,4,n5,6]), hash([n5,4,5,6])) #true 

############ 
versioninfo()
#Julia Version 0.6.2
#Commit d386e40 (2017-12-13 18:08 UTC)

5== n5 #true
isequal([4,n5,6], [4,5,6]) #true 
isequal(hash([4,n5,6]), hash([4,5,6])) # true
isequal(hash([n5,4,n5,6]), hash([n5,4,5,6])) #true 

I fear that this is fundamental to the current approach for O(1) range hashing (but I would be happy to be corrected!).

[mbauman]

So you're defining a type that is equal to a number and hashes like a number... but it isn't itself a number and doesn't support subtraction? Yeah, I can see how that'd get you into trouble in many situations. I don't think this is really actionable… or that we'd ever guarantee such a type would work everywhere.

[nalimilan]

Indeed, since #16401 a type should not be equal to a number if it doesn't support -. Honestly, that's not the biggest difficulty with that approach. :-)

[chethega]

Oh, thanks. I apparently missed the warning that if there exists y isa Number such that isequal(x, y)===true then it is assumed that x isa Number; and, for all types <:Number, widen(x) + widen(y) must be well-defined mod isequal, i.e. isequal(x,y) and isequal(x2,y2) must imply isequal(widen(x1)+widen(y1), widen(x2)+widen(y2)) (resp. for subtraction).

That's the long-term plan for a simple rule, right? I mean addition/subtraction are intentionally not well-defined mod isequal, but the code assumes that it becomes well-defined post widening; and it would be cheap to restrict the special code to things that isa Number, in order to get rid of possible bugs like hash([1,2,[]])==MethodError.

[nalimilan]

It's not clear yet what approach will be retained. See #26022.