#[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).