No easy way to #[export] custom types

[gg-yb]

I do not know if this is a bug, but at the very least it is very unintuitive.

This works:

#[derive(Copy, Clone)]
#[repr(i32)]
pub enum Alignment {
    Left = 0,
    Center = 1,
    Right = 2,
}

impl VariantMetadata for Alignment {
    fn variant_type() -> VariantType {
        VariantType::Int
    }

    fn param_metadata() -> GDExtensionClassMethodArgumentMetadata {
        GDEXTENSION_METHOD_ARGUMENT_METADATA_INT_IS_INT32
    }
}

#[derive(GodotClass)]
#[class(base=Control)]
pub struct Foo {
    #[export]
    bar: Array<Alignment>,
}

However, this does not (compiler error attached):

#[derive(Copy, Clone)]
#[repr(i32)]
pub enum Alignment {
    Left = 0,
    Center = 1,
    Right = 2,
}

impl VariantMetadata for Alignment {
    fn variant_type() -> VariantType {
        VariantType::Int
    }

    fn param_metadata() -> GDExtensionClassMethodArgumentMetadata {
        GDEXTENSION_METHOD_ARGUMENT_METADATA_INT_IS_INT32
    }
}

#[derive(GodotClass)]
#[class(base=Control)]
pub struct Foo {
    #[export]
    bar: Alignment,
}

The only difference is that the former uses Array<Alignment>, while the latter uses raw Alignment.

The error:
out.txt

[Bromeon]

VariantMetadata is very low-level, it also uses sys types directly (from crate godot-ffi). Why that API Is public, let alone in the prelude, I don't know. Possibly needed for inner workings of some other stuff.

As the error message says, the trait Export must be implemented additionally. That trait is already implemented for Array, but not for custom types.

TLDR: we should design a proper API for #[export] of user-defined types.
I would thus classify it as a missing feature.

[gg-yb]

Thank you for your response. If I understand it correctly, it currently is possible to export custom types, but only by implementing low-level / internal traits? I.e. implementing Export is not enough

[Bromeon]

If I understand it correctly, it currently is possible to export custom types, but only by implementing low-level / internal traits?

The thing is, we haven't designed for this feature yet. It may work or not, there's no documentation, stuff may suddenly break and it will be hard to find someone that can support in this case.

If you can use other ways of exporting variables, e.g. through getters returning integers, I'd highly recommend to use those for the moment.

[gg-yb]

The fact that specifying custom getter/setter that take & return values for the property as a supported type (e.g. i32) works is already very helpful. Thank you!

Of course, things are subject to change, but I'm willing to work around that :)

[lilizoey]

It is now possible to declare default export info for custom types (variant type, property hint, and property hint string). using the Export trait. This trait is likely to change somewhat in the future, but it is at least less low level than VariantMetadata et al. Though you still need to use custom setters/getters.

as an example:

pub enum GenLayer {
    Surface = 0,
    Underground = 1,
}

impl Export for GenLayer {
    fn export(&self) -> Self {
        *self
    }

    fn default_export_info() -> godot::export::ExportInfo {
        ExportInfo {
            variant_type: VariantType::Int,
            hint: PropertyHint::PROPERTY_HINT_ENUM,
            hint_string: "Surface,Underground".into(),
        }
    }
}

#[derive(GodotClass)]
#[class(base=Resource)]
pub struct MapGenLayer {
    #[base]
    base: Base<Resource>,

    #[export(get = get_kind, set = set_kind)]
    kind: GenLayer,
}

[gg-yb]

Small question for my understanding: this currently wraps and unwraps the value (e.g. GenLayer enum) in a variant, right?
Now my question is: Correctly implementing GodotFfi for GenLayer would result in optimizations where this wrapping/unwrapping could be skipped, right?

[lilizoey]

Small question for my understanding: this currently wraps and unwraps the value (e.g. GenLayer enum) in a variant, right? Now my question is: Correctly implementing GodotFfi for GenLayer would result in optimizations where this wrapping/unwrapping could be skipped, right?

well this uses a custom setter/getter that takes an i64 (since the type is VariantType::Int), i dont think implementing godotffi would really provide much benefit in terms of performance. Keep in mind that everything that crosses FFI needs to use one of the types godot accepts anyway. And enums are just integers in godot.

[gg-yb]

I see. So the example above would actually need the following code, too?

#[godot_api]
impl MapGenLayer {
    #[func]
    pub fn get_kind(&self) -> i64 { ... }
    #[func]
    pub fn set_kind(&mut self, v: i64) { ... }
}

[lilizoey]

I see. So the example above would actually need the following code, too?

#[godot_api]
impl MapGenLayer {
    #[func]
    pub fn get_kind(&self) -> i64 { ... }
    #[func]
    pub fn set_kind(&mut self, v: i64) { ... }
}

yeah

[lilizoey]

#309 should fix this, with that PR you can now implement Property and optionally Export for any type, and that will allow you to use that type in #[var]/#[export] annotations. So your example could become

#[derive(Copy, Clone)]
#[repr(i32)]
pub enum Alignment {
    Left = 0,
    Center = 1,
    Right = 2,
}

impl Property for Alignment {
  type Intermediate = i32;

  fn get_property(&self) -> Self::Intermediate {
    self as i32
  }
  
  fn set_property(&mut self, value: Self::Intermediate) {
    match value {
      0 => *self = Self::Left,
      1 => *self = Self::Center,
      2 => *self = Self::Right,
      other => panic!("incorrect value {other}")
    }
  }
}

impl Export for Alignment {
  fn default_export_info() -> ExportInfo {
        ExportInfo {
            hint: PropertyHint::PROPERTY_HINT_ENUM,
            hint_string: "Left,Center,Right".into(),
        }
    }
}

#[derive(GodotClass)]
#[class(base=Control)]
pub struct Foo {
    #[var]
    unexported_bar: Alignment,
    #[export]
    bar: Alignment,
}

#[godot_api]
impl Foo {}