Add GdDyn<dyn Trait> type

[MatrixDev]

Request

Currently it is impossible to make GodotClass object-safe because of the multiple Rust limitations.
Maybe it is possible to create a lighter alternative that doesn't require Self: Sized with limited functionality that allows to use trait-objects.

Use-case:

I have multiple different objects that have a common trait. At this moment I don't see any rust-safe way to call anything common except #[func] (which only takes variants and also a big footgun for safety).

Example

trait MyTrait {
    // cannot be made with #[func] because of the rust-specific complex type
    fn do_something_common(&self, world: &mut World);
}

let gd1: Gd<MyClass> = todo!();
let gd2: GdDyn<dyn MyTrait> = gd1.to_dyn();

gd2.bind().do_something_common(...);

[StatisMike]

Don't know if exact duplicate, maybe just a different perspective on #426

[MatrixDev]

Don't know if exact duplicate, maybe just a different perspective on #426

I saw that issue but it talks about abstract classes from the Godot's point of view. I'm asking about rust specific implementation. It is much more limited and should be easier to implement.

[Bromeon]

Let's say you have two types that you want to treat polymorphically:

#[derive(GodotClass)]
#[class(init)]
struct Monster {
    hp: u16,
}

#[derive(GodotClass)]
#[class(init)]
struct Bullet {
    is_alive: bool,
}

You can use a Health trait to abstract over them, which could then be used as follows:

trait Health {
    fn hitpoints(&self) -> u16;
}

// Use polymorphically here
fn is_dead(entity: &dyn Health): bool {
    entity.hitpoints() == 0
}

1) impl on Gd<T>

To achieve that, you can implement Health directly for the Gd pointers:

impl Health for Gd<Monster> {
    fn hitpoints(&self) -> u16 {
        self.bind().hp
    }
}

impl Health for Gd<Bullet> {
    fn hitpoints(&self) -> u16 {
        if self.bind().is_alive { 1 } else { 0 }
    }
}

fn test_health() {
    let monster = Monster::new_gd();
    let bullet = Bullet::new_gd();

    let a = is_dead(&monster);
    let b = is_dead(&bullet);
}

2) impl on T

But you can also implement it on the types directly, moving the bind() call to the use site:

impl Health for Monster {
    fn hitpoints(&self) -> u16 {
        self.hp
    }
}

impl Health for Bullet {
    fn hitpoints(&self) -> u16 {
        if self.is_alive { 1 } else { 0 }
    }
}

fn test_health() {
    let monster = Monster::new_gd();
    let bullet = Bullet::new_gd();

    let a = is_dead(&*monster.bind());
    let b = is_dead(&*bullet.bind());
}

Concrete problem

Given both of the above are possible, it would be good to describe the problem we want to solve more clearly.

For example, what would GdDyn<dyn T> solve that Box<T> or Box<Gd<T>> wouldn't? It's a bit more ergonomic and may avoid double indirection, but conceptually it doesn't unlock new features, does it?

Where would the link to Godot be? Even getting a common base could be abstracted via extra method from the trait 🤔

[MatrixDev]

@Bromeon, sometimes I want to store objects based on their functionality, not concrete implementations.

Just as an example I have a platform (parent object) with multiple types of turrets. All turrets have a common functionality (for example shoot). Now I want to iterate all turrets and shoot with each of those.

Few remarks:

• turrets are added dynamically
• there can be a lot of turret types
• I need to pass non #[func]-friendly arguments
• I need to return non #[func]-friendly arguments

struct World {
...
}

struct TurretStats {
...
}

// both function have non godot-friendly parameters/results
trait Turret {
    fn get_stats_mut(&mut self) -> &mut TurretStats;
    fn shoot(&mut self, world: &mut World);
}

#[derive(GodotClass)]
#[class(base = Node3D)]
struct TurretType1 {
}

impl Turret for TurretType1 {
...
}

#[derive(GodotClass)]
#[class(base = Node3D)]
struct TurretType2 {
}

impl Turret for TurretType2 {
...
}

#[derive(GodotClass)]
#[class(base = Node3D)]
struct Platform {
    world: World,
    turrets: Vec<Gd<...>>, // what do I put here?
}

I can have Vec<Gd<Node3D>> but there is no way to get &dyn Trait from Gd<Node3D>.
I can have Vec<Box<dyn Trait>> where impl Trait on Gd<T> but I can't return references from it because bind creates a temporary.

In short what I need is:

1. some type GdDyn<T>
2. that can be cast to GdDyn<dyn Trait> where T: Trait
3. stored for later use
4. called with bind_mut to receive impl DerefMut<Target=dyn Trait>

[MatrixDev]

Continuing with the above I think that GdDyn<T> should have following requirements / limitations:

1. must only be contructable from existing Gd<T> where T: Bounds<Declarer=DeclUser>
2. will have no trait bounds at all (or close to it), all guarantees should come from the original Gd<T>
3. will need to store additional metadata like Manual / RefCounted or what else it might need to support drop, bind, bind_mut
4. will implement bind and bind_mut
5. can be made downcast-able to Gd<T> (something similar toAny)
6. maybe with some magic it can also be made cast-able to Gd<B> where T: Inherits<B>

[Dheatly23]

Unfortunately, RTTI with trait object (donwcast(...) -> T where T: Trait) is currently impossible (excluding mopa and such). Even if there is a GdDyn<dyn Trait>, it can't guarantee the pointed value does implement that trait. There is a nightly feature CoerceUnsized that may allow for that, and builtin types (Box/Rc/Arc) use it to ensure it's okay to do so (Arc<T> -> Arc<dyn Trait>).

EDIT:
Oh you want cast from Gd<T> to GdDyn<dyn Trait>. I guess that's one way to guarantee that value implement trait. But my point still stands.

Let's say i got a Gd<Node> for example, how is it going to be cast to GdDyn? There are 2 possible route:

1. Try to convert to every concrete type that implements trait, then recast them to GdDyn. I guess that works, but it's very unergonomic.
2. Somehow smuggle GdDyn with multiple dispatch 🤷‍♂️. I am not sure how it's done and i don't think it's the right approach.

You see, Gd<T> points to any type that is T or it's decendants. So in a sense, T is a trait, even though it's not obvious. The only exception is user-defined types, which can be bind() to obtain non-DST borrow.