Problem with usize/i64 mismatch for indices in custom array-like APIs

[v1993]

I have a Resource that provides an API to access its two arrays as if they were continuous (one is created manually and the other one is baked). On the Rust side of things I'd like to have index be a usize - which both fits logically and is consistent with other index types godot-rust exposes (e.g. those of PackedArray) - yet usize can't be used in Godot-facing interfaces due to type restrictions and i64 must be used instead. Since there's no function renaming or overloading available I currently have to deal with a rather silly workaround:

#[derive(GodotClass)]
#[class(init, tool, base = Resource)]
pub(crate) struct MyResource {
	#[var(pub)]
	#[export]
	manual_points: PackedVector3Array,

	#[var(pub)]
	#[export]
	generated_points: PackedVector3Array,
}

#[godot_api]
impl MyResource {
	pub fn get_point_rs(&self, index: usize) -> Option<Vector3> {
		self.manual_points
			.get(index)
			.or_else(|| self.generated_points.get(index - self.manual_points.len()))
	}

	#[func]
	fn get_point(&self, index: i64) -> Result<Vector3, Unexpected> {
		let index = index.try_into()?;
		Ok(self.get_point_rs(index).ok_or("Tried to get a non-existent point")?)
	}

	pub fn get_point_count_rs(&self) -> usize {
		self.manual_points.len() + self.generated_points.len()
	}

	#[func]
	fn get_point_count(&self) -> i64 {
		self.get_point_count_rs().try_into().unwrap()
	}
}

I see two ways out of this:

1. Implement ToGodot/FromGodot for usize - debatable due to conversion being able to fail, but would eliminate the need for separate functions in this scenario
2. Allow overriding function names in #[func] (e.g. #[func(name = "new_name")]) so that Rust and GDScript versions of functions could keep identical names

[Yarwin]

Renaming functions is supported, but surprisingly undocumented (there is even an alias):

#[godot_api]
impl MyClass2 {
    #[func(rename = bar)]
    fn foo(&self) {...}
}

[Bromeon]

It would be nice to have usize, but our experience with u64 showed that it causes more problems than it solves.
It's slightly inconvenient, but your game doesn't panic in random scenarios.

If you have these conversions more often, you can maybe consider a closure?

[v1993]

Renaming functions is supported, but surprisingly undocumented (there is even an alias)

Having read through both the book and the API docs to make sure this wasn't an existent feature I have to admit I'm about as surprised as you! I guess this would make this largely a documentation issue, the following works nicely for me:

#[derive(GodotClass)]
#[class(init, tool, base = Resource)]
pub(crate) struct MyResource {
	#[var(pub)]
	#[export]
	manual_points: PackedVector3Array,

	#[var(pub)]
	#[export]
	generated_points: PackedVector3Array,
}

#[godot_api]
impl MyResource {
	pub fn get_point(&self, index: usize) -> Option<Vector3> {
		self.manual_points
			.get(index)
			.or_else(|| self.generated_points.get(index - self.manual_points.len()))
	}

	#[func(rename = get_point)]
	fn get_point_gd(&self, index: i64) -> Result<Vector3, Unexpected> {
		let index = index.try_into()?;
		Ok(self.get_point(index).ok_or("Tried to get a non-existent point")?)
	}

	pub fn get_point_count(&self) -> usize {
		self.manual_points.len() + self.generated_points.len()
	}

	#[func(rename = get_point_count)]
	fn get_point_count_gd(&self) -> i64 {
		self.get_point_count().try_into().unwrap()
	}
}

I guess duplicate docs would be the biggest annoyance at this point.

It would be nice to have usize, but our experience with u64 showed that it causes more problems than it solves. It's slightly inconvenient, but your game doesn't panic in random scenarios.

If you have these conversions more often, you can maybe consider a closure?

I have mixed feelings about this - the situation is fairly clear with u64 not being representable in godot, but usize <-> i64 conversion is kind of weird with how usize is the canonical type for indices in rust while i64 is on godot side and, arguably, you already can get surprise panics around this very mismatch when calling certain APIs.

I'm not sure what exactly you mean by using a closure here? Maybe a usize newtype with To/FromGodot could be helpful here, although this means still means slightly worse ergonomics on Rust side compared to a helper function.

[Bromeon]

[...] arguably, you already can get surprise panics around this very mismatch when calling certain APIs.

The thing is that there's no real way around this conversion, because things like the Iterator trait require usize in Rust, and we can't reasonably represent Godot collections without this type. But limiting this to a few engine APIs means there's much less potential for accidental misuse.

---

I have mixed feelings about this - the situation is fairly clear with u64 not being representable in godot, but usize <-> i64 conversion is kind of weird with how usize is the canonical type for indices in rust while i64 is on godot side and,

I agree, but the whole "is not representable" doesn't apply any less because of that 🤔

How would you implement this (1)?

#[func]
fn return_usize() -> usize {
    usize::MAX
}

Or this (2)?

#[func]
fn accept_usize(u: usize) {
     dbg!(u);
}
// GDScript calls accept_usize(-1), what is printed?

Or variant conversion (3)?

let u1 = usize::MAX
let v = u1.to_variant();
let u2 = usize::from_variant(&v);
// u1 == u2 or not?

And then the next question is, if #[func] allows usize, wouldn't users expect it to work in other places?
#[var]? #[export]? #[signal]? #[constant]? Array<T>?