Call emit_changed() automatically for custom Resource properties, or add an @emit_changed annotation

[sscovil]

From the Resource class docs:

Signals

changed ( )

Emitted when the resource changes, usually when one of its properties is modified. See also emit_changed.

Note: This signal is not emitted automatically for properties of custom resources. If necessary, a setter needs to be created to emit the signal.

When creating a class that extends Resource, if you want to emit the changed signal any time the value of a custom property is changed, you need to implement a custom setter for that property, like this:

class_name MyCustomResource
extends Resource

@export
var some_property: String:
	set(value):
		some_property = value
		emit_changed()

Doing this for more than a couple of properties can add a lot of unnecessary boilerplate to your custom resources. It would be avoided entirely if calling emit_changed() were the default behavior for resource properties.

Possible Implementation: Modify core/io/resource.cpp to override the _set method:

bool Resource::_set(const StringName &p_name, const Variant &p_value) {
    // Call the base class _set method
    bool result = Reference::_set(p_name, p_value);
    
    emit_changed();
    
    return result;
}

Alternatively, to avoid any compatibility issues, a new @emit_changed annotation could be added to GDScript:

class_name MyCustomResource
extends Resource

@export
@emit_changed
var some_property: String

Possible Implementation: This would require an additional change to add modules/gdscript/gdscript_parser.cpp, to add the annotation, but otherwise I imagine the change to core/io/resource.cpp would look something like this:

bool Resource::_set(const StringName &p_name, const Variant &p_value) {
    // Call the base class _set method
    bool result = Reference::_set(p_name, p_value);

    // Check if the property has the emit_changed annotation
    if (_has_emit_changed_annotation(p_name)) {
        emit_changed();
    }

    return result;
}

Curious to hear what you all think. If enough folks like the idea, I'd be happy to take a crack at contributing a PR.

[theraot]

I think we could have the annotation set a property usage bit flag (which we could also set by other means), and then _set can check the peroperty usage.

[AThousandShips]

Without an annotation this isn't something that should be done IMO, emitting this on any property change isn't desirable or recommend, but an annotation does make sense

However having the signal emit without there being any behaviour change in the resource doesn't necessarily make sense, I'd say the signal should be emitted not when a property changes as such, but when the resource itself is modified in some deeper way, i.e. changes how it's rendered or behaves, and this usually involves having it act when the property is set

I'd say the signal communicates that the resource has updated its total state and should be responded to, when for example a dynamic texture recreates its internal state, i.e. it doesn't reflect the way others can respond by reading its properties, but by reading the data and behaviour those properties control

[dalexeev]

I think this is one of those issues that could be solved by reusable setters/getters (godotengine/godot#78991), custom annotations or something else. We have many related proposals such as @observable annotation (#4867). But I have the same concern about them all: a language should not solve too specific problems, but should provide facilities to solve a wide range of problems. Yes, GDScript is a domain-specific language, but even within Godot there are too specific cases.

This is especially true for syntactic sugar and other shorthands. I think that a good shorthand is characterized by simplicity and lack of alternatives. It does exactly one thing that must be clear and cannot be done any other way. There is either no room for customization at all, or the parameter(s) are obvious and the behavior itself is still straightforward.

If each of your properties is unique enough, then I think the boilerplate is ok, there shouldn't be too many properties for this to be a big problem. If you have a lot of homogeneous properties, then you can use different approaches to reduce the boilerplate:

1. Dynamic properties implemented with _get_property_list(), _get() and _set(). Disadvantages: lack of static typing and autocompletion, need for @tool to display properties in the inspector.
2. set_something() / get_something() plus enum (you can use a string, integer, or other identifier instead of an enum, if you want an open list). More verbose syntax, no properties in the inspector, but you can combine this with approach 1.
3. Existing properties + setters/getters. Advantages in static typing, short syntax, autocompletion. Disadvantage: there is still a little boilerplate because there is currently no way to distinguish for which property the setter/getter is called when it is reused for several properties.

[sscovil]

Interesting. Thank you @AThousandShips for helping me better understand the thinking behind the changed signal and its intended usage. I can see how emitting this signal on every property change could get very noisy, and require a lot of conditional logic elsewhere to determine when- and whether to handle the signal. Makes sense. 👍

Also, I very much agree with your sentiment @dalexeev about providing facilities to solve a wider range of problems. I love the idea of being able to create custom annotations, so I'll keep an eye on that instead. 🙏