Chitose Yuuzaki

@chenyukang I have already opted for the newtype workaround, since while I'm relatively sure that *this* use case is sound, there are probably reasons to disallow mutable references by default...

This should've been fixed in #970 I think?

> The extra parameter `exact` is optional, which is a non-breaking change in GDScript and C++, but a breaking one in Rust, since the language does not support default parameters....

From a broader view, there is the question of what "engine compatibility" actually means. For reference, there are currently two definitions of a compatible engine in the README: - The...

> 1\. Is compatibility with multiple Godot versions a feature that many users benefit from? This is one of those things that are very hard to tell, due to selection...

Sounds like a good idea to me! This should deal with ABI compatibility issues to the extent that is possible on our side, although ideally we'd still want to (separately)...

> `TypedArray` -> `PoolArray` > Would immediately reflect that it's the Rust counterpart of GDScript's `Pool*Array`s. > We need to decide if it makes sense to keep `Int32Array` and `Float32Array`...

I think https://github.com/godot-rust/godot-rust/issues/869#issuecomment-1068641915 is the approach one would have taken if the traits were to be designed from scratch. This is the same way serde and co does it. The...

> May I ask how this affects existing code (since it's marked as a breaking change)? It technically splits `NativeClass`, but since most user code doesn't directly touch those types,...

> So the derive-macro would detect whether it's applied to a generic class (-> no name) or not (-> name)? > Or the trait is always implemented but not always...