Support `rename` for `#[var]`

[ttencate]

It exists for #[func] and #[class], so this just seems like an oversight.

It's especially useful in combination with the new PhantomVar (#1261) since you could have a Rusty-typed field exposed to Rust and a Godoty-typed field exposed to Godot with the same name, e.g.

    name: String,

    #[var(rename = "name", get = get_name, set = set_name)]
    _name: PhantomVar<GString>,

As a user, I'd expect this to rename (the Godot side of) autogenerated getters and setters as well.

[sylbeth]

Do renames outlaw certain characters? Identifiers with inner # can't be used from GDScript for example

[ttencate]

The new name would need to be a valid identifier in GDScript, I suppose.

[sylbeth]

Are those checks in place? Also, that part seems poorly written because "most of this" isn't a good definition.

[ttencate]

🤷 I don't think it matters much, because most people just use ASCII letters, underscores and the occasional digit. We could also just pass the string through verbatim and let people get syntax errors when trying to access it from GDScript. Apparently this is what we do in other places already, as you found out with r#raw identifiers.

[sylbeth]

Well, more than erroring, they exist but aren't reachable, which is simply frustrating. Signals can bypass this completely, functions only sometimes. It's just weird.

[Bromeon]

Well, more than erroring, they exist but aren't reachable, which is simply frustrating.

I think this is something to be addressed with Godot. If the engine allows to register classes, properties, functions, signals and constants with names that cannot be used, that indicates a bug.

But I agree with @ttencate, it's not a big deal. So unless someone is willing to put in the work to fix this, just creating an issue won't move anything 😉

[Bromeon]

On-topic: would rename also make sense for #[constant]?

I don't think we should support it for signals, to be honest. But we can document that it's deliberately absent.

[sylbeth]

would rename also make sense for #[constant]?

What is the actual use case for rename? I did remember I wanted to use it for fields once, but not why. Constants clashing names are not as common, I think, plus no rust keywords would clash, but it could be used for consistency. If you have a field name potato that you export to godot as tomato, it makes sense an associated constant to it in rust side would be called POTATO_SIZE and in godot TOMATO_SIZE. Plus, since non int constants are implemented as functions, allowing renaming there and not here feels inconsistent too.

I don't think we should support it for signals, to be honest.

Why tho? Are rpcs also renamable?

[Bromeon]

Hm, maybe we should indeed wait for concrete use cases for both #[constant] and #[signal], and only implement them if there's broad user support + use cases.

#[var] should be OK. We need to make sure that we don't fall into a rabbit hole like #1019, but for now, I don't think anything refers to fields/properties in a type-safe way.

[sylbeth]

wait for concrete use cases for both #[constant]

I did give a concrete use case for constant, though. I believe constants are sometimes closely associated with either specific functions or specific fields, and if they are renamed, so should be the constants to make consistency across rust-space and godot-space, separately.

I don't think anything refers to fields/properties in a type-safe way.

What do you mean?