Derive Hash for Rect2i

[ttencate]

Also add Hash, PartialOrd and Ord for some enums while I have my eyes on them.

Related issue: #505. There seems to be no objective to keep Godot and Rust hashes the same, so this change should be fine, and is indeed consistent with prior art of deriving Hash on e.g. Vector2i.

[GodotRust]

API docs are being generated and will be shortly available at: https://godot-rust.github.io/docs/gdext/pr-1241

[Bromeon]

Thank you! I see deriving Hash for the enums, but what prompted it for Rect2i?

[ttencate]

A bit obscure, I'll admit. I've built a framework similar to LayerProcGen to generate terrain procedurally in chunks. However, mine is a bit more generic: a "chunk" can be identified by anything, not just by (x, y) coordinates – as long as it implements Eq and Hash (since the chunks in each layer are stored in a hash map internally).

Now I've come to the point where I want to generate maps of part of the world, which will be on a different procgen layer. A map is identified by, among other things, a Rect2 indicating which part of the world it covers. So this is part of its key, and therefore needs to be hashed as well.

We all know that floats shouldn't be hashed, so I did self.rect.cast_int().hash(hasher); which is still a valid hash function. It's good enough for me since these floats represent meters and maps cover several kilometers, so the rounding almost never leads to hash collisions. Except it didn't compile because Rect2i doesn't implement Hash :)

[Bromeon]

Thanks for explaining! Makes sense 👍

[Bromeon]

For future, please don't merge directly. I have to prepare a hotfix release today (see #1247) and did not plan to add any features in that version.

I see that the approval was misleading, I meant it in a "no longer needs any changes" sense, otherwise I could have merged immediately. But this change is low-risk, so no big deal 😉

[ttencate]

Apologies. Won't happen again :)