C#: Tween.TweenProperty()'s NodePath parameter is not compatible with PropertyName

[kennypu]

Godot version

4.2.dev5.mono.official

System information

Godot v4.2.dev5.mono - Windows 10.0.22621 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; 31.0.15.3699) - 12th Gen Intel(R) Core(TM) i5-12600K (16 Threads)

Issue description

I believe this is more of an issue with NodePath vs StringName, but when providing a PropertyName to Tween.TweenProperty() you will get an error: cannot convert form 'Godot.StringName' to 'Godot.NodePath'.

The workaround is of course simple: Just append .ToString().

However, In various locations in the documentation where property_name is needed, it is recommended to use PropertyName . I would think the expectation would be that the above line should work without issue, and without having to convert PropertyName.SomeName to a string. This recommendation is also used in the documentation of get_indexed(), in which case if a developer were to follow the directions in the documentation, they will find that just using PropertyName will result in an error.

Steps to reproduce

Minimal Example

// This should be expected to work, but will produce an error
CreateTween().TweenProperty(this, Node2D.PropertyName.Position, Vector2.Zero, 1.0f);

// Adding .ToString() to the property_name is needed
CreateTween().TweenProperty(this, Node2D.PropertyName.Position.ToString(), Vector2.Zero, 1.0f);

Minimal reproduction project

N/A

[kleonc]

I believe this is more of an issue with NodePath vs StringName

Indeed seems like a core issue / duplicate of #71319, as the cause is no implicit StringName to NodePath conversion. It's not C# specific:

[raulsntos]

In various locations in the documentation where property_name is needed, it is recommended to use PropertyName. [...] This recommendation is also used in the documentation of get_indexed()

I think that note in the documentation should be removed from the get_indexed method. Methods that take NodePath shouldn't recommend you to use the StringName fields.

I think the reason why the TweenProperty method takes a NodePath instead of a StringName is so that you can also specify subnames, for example position:x.

Adding an implicit conversion from StringName to NodePath has already been suggested in a proposal: godotengine/godot-proposals#7602. I think adding an implicit conversion is fine for GDScript, but I wouldn't do it in C# because it's expensive.

The reason why we tend to recommend using the cached StringName fields is that it prevents allocating a new StringName:

// This is bad because it allocates a new StringName.
// For C# users it's also a bit confusing having to use snake_case for the names of native properties.
position = node.Get("position");

// This uses a cached StringName, so no new allocations.
position = node.Get(PropertyName.Position);

In the TweenProperty method, since it takes a NodePath, using the cached StringName fields would be worse since you have to allocate a string and a NodePath:

// This is bad because it allocates a string, and then a NodePath (2 allocations).
CreateTween().TweenProperty(this, Node2D.PropertyName.Position.ToString(), Vector2.Zero, 1.0f);

// This is not great, but a bit better, because it only allocates a new NodePath.
// For C# users it can also be a bit confusing having to use snake_case for the names of native properties.
CreateTween().TweenProperty(this, "position", Vector2.Zero, 1.0f);

An implicit conversion from StringName to NodePath would just hide the allocations and the marshaling cost. If #72702 is merged, then we can skip the string conversion and go directly from StringName to NodePath but there's still an allocation and some marshaling there, so if we were to implement a conversion in C# I would make it an explicit conversion.

// If we implement an explicit conversion we could do this:
CreateTween().TweenProperty(this, (NodePath)Node2D.PropertyName.Position, Vector2.Zero, 1.0f);

[markdibarry]

Would it be problematic to just make an overload then if the problem will be there either way?