@Tamas_Papp in that case, I stand corrected. Users have to implement == and hash. Because there are cases where == should not behave like ===. Below is an example.
https://github.com/sambitdash/IntervalTrees.jl/commit/ec83e2a49123683ac786bd27e472455501a7e15d
I don’t think anyone suggested that == should behave like ===; if they did, one would not need two functions.
The only connection I am aware of is that a === b should imply a == b for most cases, but note
julia> NaN == NaN
false
julia> NaN === NaN
true
so even that can be violated when that makes sense. The converse is of course not expected to hold in general.
Notions of equality are notoriously difficult in programming with various ramifications (eg ordering, hashing). IMO the approach that seems to work best is practical: define equality to have a simple mental model users can reason about, and refine this as needed by uses cases, with the understanding that sometimes it is just better to use another function for a different notion of equality.
Fortunately, doing this has zero or negligible cost for Julia, in terms of syntax (nice unicode infix ops), implementation (multiple dispatch with fallbacks), and runtime (zero-cost if done well).
Finally, probably the most important thing about various concepts of equality is documentation. I think this improved a lot in v0.7, the user can now traverse the docs of <=, <, and isless to learn what the semantics are. If you think they should be clarified, perhaps you could open an issue or PR.
@Tamas_Papp in short the 0.7 behavior is different from 0.6. Most data structures when do sorting or searching depend on only one operator (mostly lessthan). The others are automatically ordered with well defined order preserving fallbacks. With the change in 0.7 there is a potential test needed to ensure == is behaving properly. And that has to be documented.