#[func] should not pass types not representable in GDScript

[Bromeon]

Since #326, we use the same mechanism to pass types from/to the engine API (Rust -> Godot) as well as from to the bind API (GDScript -> Rust, via #[func]). This is generally a good thing, but for some types it's problematic.

For example, u64 is not representable in GDScript, so we should discourage accepting and returning u64 in #[func]. GDScript always uses i64 as int, so there is going to be an implicit conversion which can lead to a different value.

However, such a #[func] API may have uses in the rare cases where another language (C++, C# or even Rust?) calls our Rust API.

There are multiple options:

• two separate traits for GodotFuncMarshal, one for bind and one for engine API
• a wrapper newtype UnstableU64(u64) or so
  • #[func] API would require explicit packing/unpacking
  • engine API could accept impl Into<UnstableU64> parameters -- but what about return types?
  • instead of going via trait, the engine codegen could use a hardcoded special case

[Bromeon]

Relevant code:

gdext/godot-ffi/src/godot_ffi.rs

Lines 605 to 607 in 565bf10

	// Some places Godot will pass along 64-bit numbers that are intended to be interpreted as unsigned
	// integers despite Godot integers being signed by default.
	impl_godot_marshalling!(u64 as i64; lossy);

[Bromeon]

Related: #105 and #125

[Bromeon]

Closed by #700.

We still allow u64 in #[func] parameter and return type positions, but panic if the value is larger than i64::MAX. For now, I think this is a good trade-off and avoids duplicating the entire marshalling mechanism for such edge cases.

Users are generally encouraged to use i64 when interfacing GDScript.