Derive Hash for integer Vector types

[B4rc1]

Related: #297

My Usecase: Putting Vector2i's in a HashMap

[lilizoey]

Hm, do you think it would be better for us to reuse godots hash implementation here?

[B4rc1]

I think for more complex data types such as Vector2 or a general (macro assisted) solution, yes, because e.g. f32 does not implement hash by default.

But for this specific case deriving should be fine as hashes are never shared across the FFI-Interface (correct me if I'm wrong) and there are no conventions to consider.

A convention would be the case of a NaN float, should all NaN floats be the same? Should they all be different? Should they be different if the mantissa/exponent is different?

[GodotRust]

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

[Bromeon]

Sounds like a useful addition, thanks! One minor comment (please amend the 1 commit instead of adding a new one).

As for the question whether we should use Godot's hash, it's probably a wider discussion. Things to consider:

• Eq + Hash + Ord must play together in a consistent way.
• If we use Godot's impl, we need to either call FFI or maintain a separate implementation, both of which come with drawbacks.
• Godot's impl may have different trade-offs regarding performance or security (not sure how applicable in gamedev domain, but something to keep in mind).
• At the moment, Variant::from(x) and x have different hashing and equality relations, which may or may not be OK.

These are for a separate discussion though; a feature request with use case + rationale would be nice. Either way, making integer vectors hashable is relatively uncontroversial. The implementation can also be changed later, which should be transparent to the user. Or we could consider adding special functions or wrapper types for Godot-based equality/ordering/hashing.

[Bromeon]

Nitpick: Hash should come before Debug.

(I still need to write these conventions down somewhere...)

[Bromeon]

Thanks!