GDScript: Add @export_storage annotation

[dalexeev]

• Closes Ability to declare exported properties that are not shown (aka hidden) in inspector godot-proposals#7794.

I'm not sure about the name: @export_hidden, @export_storage or @export_no_editor.

Also PROPERTY_USAGE_NO_EDITOR is currently the same as PROPERTY_USAGE_STORAGE, but in the future we may add other default flags (PROPERTY_USAGE_NO_EDITOR is PROPERTY_USAGE_DEFAULT without PROPERTY_USAGE_EDITOR).

@export ≈ PROPERTY_USAGE_DEFAULT
@export_hidden = PROPERTY_USAGE_NO_EDITOR (default without editor)

vs

@export ≈ PROPERTY_USAGE_DEFAULT
@export_hidden = PROPERTY_USAGE_STORAGE (only storage)

[YuriSizov]

I think export_storage is the best option as it says what the annotation does do, not what it doesn't do. But this invites back the debate about the name and function of export annotations, kinda. Well, maybe this can give us closure.

[AThousandShips]

Using something like "no editor" like the flag could be the most uniform, but I think that hidden risks being confusing

Edit: as in, either first option with @export_no_editor or second with @export_storage

[limbonaut]

Perhaps a new annotation would be more clear? For example:

@serialize var data: MyData  # == PROPERTY_USAGE_STORAGE

[dalexeev]

I would prefer that the annotation name start with @export_ for consistency and clarity. We also have a check that several export annotations cannot be applied to one variable; an exception in the naming would be confusing in my opinion.

[limbonaut]

The intent for this functionality is often to save some data with the scene/resource file without exposing it to the inspector. So I think @export_storage == PROPERTY_USAGE_STORAGE is a good fit.

[dalexeev]

So I think @export_storage == PROPERTY_USAGE_STORAGE is a good fit.

Yes, this looks like a good option to me. But the question is what default flags we can add in the future, and whether we will later regret not choosing @export_no_editor == PROPERTY_USAGE_NO_EDITOR. Although in this case we will still be able to add this too and it will be consistent.

[YuriSizov]

I think @export_storage == PROPERTY_USAGE_STORAGE for user code would be fine and follow the principle of least surprise. If we expand "no editor"/"default" to do more, we'd have to consider what that changes for user scripts anyway, so I think we can cross that bridge when we get there.

[YuriSizov]

Aside from a few comments, I'm approving the design of this (and implementation seems fine as well).

[Kakiroi]

Since #82843 now disallows using @ export to hold node reference in resource, will this be a viable option? Will this bypass the error?

[AThousandShips]

This doesn't change the underlying issue of the access of Node from Resource, and specifically storing the value is what is not working, as opposed to having just a reference to it

So I'd say this PR doesn't change that PR at all

[Kakiroi]

This doesn't change the underlying issue of the access of Node from Resource, and specifically storing the value is what is not working, as opposed to having just a reference to it

So I'd say this PR doesn't change that PR at all

So this annotation will still forbid users from having duplicatable node variable in resource? The warning is there because of exported variable having node path, not reference. I was hoping using this annotation wouldn't trigger that warning. Since there's no way users can assign node path in the resource anyway.

[AThousandShips]

It's not possible to store a Node reference, they are always stored as a path, that's why it's forbidden, you're getting it backwards, this PR allows you to have exports not visible in the editor but only in storage

[YuriSizov]

This needs a rebase (and a review from the @godotengine/gdscript team).

[adamscott]

As shared by @dalexeev during the GDScript meeting, this PR seems to overlap with #72912.

Maybe we should only expose @export_custom with the ability to use PROPERTY_USAGE_STORAGE or PROPERTY_USAGE_NO_EDITOR as flags for the property.

We all agree that we should not have features that overlap too much.

[dalexeev]

We all agree that we should not have features that overlap too much.

Note that @export_custom is more verbose and resets the hint and usage flags ("reflection" with get_property_list()), unlike @export_storage. You can also replace any @export annotation with @export_custom, so this argument doesn't always work.

[vnen]

LGTM

[akien-mga]

Thanks!