Crystal: Unexpected equality behavior between some types

[vegai]

[RX14]

I'm sure there's been discussion of this before but github's issue search is useless :(

It's not going to be implemented, anyway, change the implementation yourself and see what happens.

[straight-shoota]

I'm not sure if there's a dedicated thread about this. But #5829 for example touches this and should explain why equality is defined between any two types. It doesn't necessarily need to be like that, both ways could be taken. But we've come so far with the current behaviour and it's unlikely to change such a fundamental concept at this point.

[straight-shoota]

Btw. some other methods enjoy the same type flexibility: ===, !=, =~, !~ (see #5829) and some collection methods (see #988, #1764). Hash lookup methods also don't have type restrictions, but that will probably change (#8893). There's also an open discussion about making <=> generally applicable (#8953).

[asterite]

How do you implement [1, "a"].includes?("a") if you can't freely compare any two types?

Maybe we can introduce another operator to compare types in a non type safe way. Then the general collection methods can use it, but when using == it will be type safe. Same goes for <=> and possibly others.

[asterite]

I wouldn't discard this possibility.

[RX14]

That seems worth an experiment, though IDK if it's worth changing the language this late

[asterite]

For the type-safety, I think it might be worth it.

[girng]

To answer your question (and give my opinion) I think they should. The compiler is our best friend, the more bugs it can catch, the better the developer is in the long run.

[jhass]

I'm confused what the action item or even discussion topic of this issue is at this point. Could somebody please clarify by updating the issue title to something sane? Or better yet close this off and write a proper proposal for whatever it is?