`#[export(file)]` should be limited to certain field types

[snatvb]

If user tries convert @export_file("*.txt") to Array:

extends Node

class_name NewScript

@export_file("*.txt") var files: Array[String]

LSP shows error:

And in console:

But if user does it in rust:

#[derive(GodotClass)]
#[class(init, base=Node)]
struct Foo {
    base: Base<Node>,
    #[export(file)]
    resources: Array<GString>,
}

#[godot_api]
impl INode for Foo {}

It leads to this:

For user it's unexpected and it would be rather to notify about incorrect annotation.

Reprocase: godot-rust-repro.zip

Discord source conversation

[snatvb]

godotengine/godot#93366
Created on Godot, if there is no point in improving the macro, you can close it down

[lilizoey]

godotengine/godot#93366 Created on Godot, if there is no point in improving the macro, you can close it down

i dont see why this issue should be brought up to godot

[snatvb]

i dont see why this issue should be brought up to godot

Bromeon said that it's issue of Godot that it doesn't notify about incorrect export property

[Bromeon]

Sorry about the confusion here, tried to clarify it on the Godot issue.

I'm not sure whether Godot performs the same validations for @export_* annotations in GDScript as it does for GDExtension property hints. If it doesn't (and there is no change planned), then we would need to replicate them on Rust side, which could be quite laborious and maintenance-intensive.

[Bromeon]

@export_file on Array

Since GDScript doesn't support this annotation to be used on Array[String], we should probably follow and provide a compile-time (or startup) error.

---

Error message

From dsnopek's comment on the upstream issue:

I suppose we could put similar validation in ClassDB::add_property(), however, the error message couldn't really be as good.

From Godot's perspective, it's looking at data passed on the PropertyInfo struct, and the error message could only refer to that (for example, saying the PropertyInfo::hint won't work with the given PropertyInfo::type). However, the binding probably doesn't directly expose PropertyInfo, but instead some binding-specific way of doing it, and so it'd be able to provide a better error message that refers to that.

So, I personally think giving a nice error message should be up to the GDExtension binding (in this case, the Rust binding).

TLDR there's limited things that can be done on Godot side, and a more specific error message on our side (tailored to Rust APIs) probably makes sense.

[snatvb]

Won't it support in 4.3? I've seen some information with improvement this part. Maybe I'm wrong, can't find anymore :(

[Bromeon]

I don't know -- do you have the time to test your example with a recent 4.3 beta release?

[snatvb]

not really, it requires build
it's still a little difficult for me
you can hold the task until 4.3 is released

[Bromeon]

No need to build -- you can get nightly artifacts from https://github.com/Bromeon/godot4-nightly/actions 🙂

Just click on the latest workflow run, scroll down and select the matching artifact for your platform (e.g. godot-windows-nightly).

[Bromeon]

@snatvb so it looks like we would need to add validation on godot-rust side.

I have an idea how to validate this in a lightweight way. To be clear, I don't want to make the type-system more complex by adding niche traits, or worse, handling at the proc-macro level. I'm very fine with having this validation during startup rather than at compile time.

The export_file implementation currently looks like this:

pub mod export_info_functions {
    pub fn export_file<S: AsRef<str>>(filter: S) -> PropertyHintInfo {
        ...
    }
}

with PropertyHintInfo (this one shouldn't be changed, as it's used in other places):

#[derive(Clone, Eq, PartialEq, Debug)]
pub struct PropertyHintInfo {
    pub hint: PropertyHint,
    pub hint_string: GString,
}

Now to support this, all export functions could additionally (in a tuple) return a validator function, which would be |_| true by default.

type ValidateExportType = Box<dyn Fn(&PropertyInfo) -> bool>;
// or:
type RestrictExportType = Option<Box<dyn Fn(&PropertyInfo) -> bool>>;

The PropertyInfo passed to it can be obtained as <<FieldType as Var>::Via as GodotType>::property_info():

gdext/godot-core/src/meta/traits.rs

Lines 89 to 98 in adcb58d

	#[doc(hidden)]
	fn property_info(property_name: &str) -> PropertyInfo {
	PropertyInfo {
	variant_type: Self::Ffi::VARIANT_TYPE,
	class_name: Self::class_name(),
	property_name: builtin::StringName::from(property_name),
	hint_info: Self::property_hint_info(),
	usage: PropertyUsageFlags::DEFAULT,
	}
	}

In this case for example, we could then return:

|info| {
    info.variant_type == VariantType::STRING // maybe STRING_NAME and NODE_PATH are OK, too
}

Should be relatively straightforward to implement.

[snatvb]

@Bromeon as I remember there is issue that I have no option to add file-type for array. If I want to use several resources and take file path - I can't do it. For example it could be textures. When I use @export_file("*.txt") - it gives me not regular text input, it gives me file input control and I can limit extensions.