Add extensible serialization for C#

[tehKaiN]

It'd be best to be able to fix GD0102 for every C# type, not only System.Collections. How about adding means of being able to define custom (de)serializers for given type/field by implementing custom (de)serializers?

using System.Collections.Generic;
using Godot;
using Godot.Collections;

namespace MyAwesomeProject
{
    [GlobalClass]
    public partial class TestResource : Resource
    {
        [Export]
        public int intProp = 5;

        [Export]
        public List<int> listProp = new() { 3, 4, 5 }; // Currently throws GD0102
    }
}

namespace GodotSharp
{
    public partial class Serialization
    {
        // Serialization implementation strictly for List<T> - added either in same or separate file.
        // If it can support generics, then great! If implementations must be non-generic then it would be good enough as well - could be as easy as doing wrappers around generic serializer.
        // Perhaps some other attribute, e.g. MustBeSerializable? Dunno if `int` satisfies MustBeVariant
        public static Error Serialize<[MustBeVariant] T>(List<T> data, out Variant serializedData)
            where T : class
        {
            var serializedList = new Array();
            serializedList.Resize(data.Count);
            for (var i = 0; i < data.Count; ++i)
            {
                var error = Serialize(data[i], out var serializedElement);
                serializedList[i] = serializedElement;
                if (error != Error.Ok)
                {
                    serializedData = new Variant(); // nil?
                    return error;
                }
            }

            serializedData = serializedList;
            return Error.Ok;
        }

        public static Error Serialize<[MustBeVariant] T>(Variant serializedData, out List<T> data)
        {
            // Reverse of the above...
        }

        public static Error Serialize<[MustBeVariant] T>(T data, out Variant serializedData)
        {
            // Builtin inside godotsharp...
        }
    }
}

There are some problems needing ironing out like duplicate (de)serializers for given type in case of attaching multiple addons to the project, but some reasonable solutions could be found, I think.

Would that thing be even doable in current c# backend? I'm willing to writing proper proposal and help adding this stuff in if someone from the team at least initially green-lights it.

[tehKaiN]

Ok, so I see some upvotes, and no comments against it, so perhaps it's worth putting a bit more thought to it.

The biggest problem with proposed approach is (de)serializer function declaration conflict when using e.g. C# addons which declare them for same types (e.g. System.Collections) as the main project. This could be fixed with attributes, but needs extra thought. I think that specifying attributes per-member would litter the class and make it less readable, but perhaps a per-class attribute would do the trick:

namespace MyAwesomeProject
{
    [GlobalClass]
    [SerializerNamespace="MyAwesomeProject.Utility"]
    public partial class TestResource : Resource
    {
        [Export]
        public int intProp = 5;

        [Export]
        public List<ClassInOtherLibrary> listProp = new(); // Currently throws GD0102
    }
}

// Perhaps in other file:

namespace MyAwesomeProject.Utility
{
    public partial class Serializer
    {

        public static Error Serialize<[MustBeVariant] T>(List<T> data, out Variant serializedData)
            where T : class
        {
            // ...
        }

        public static Error Serialize<[MustBeVariant] T>(Variant serializedData, out List<T> data)
        {
            // ...
        }
    }
}

I assume that ClassInOtherLibrary would have its own SerializerNamespace attribute which could have completely different value and it should be respected to invoke proper (de)serializers.

One small minus is that SerializerNamespace attribute can't use nameof() for the value because it will break with nested namespaces.

The thing of my most concern for this solution would be NativeAOT support. Being a C# novice, I assume that parsing attributes would involve reflection, which might not play nice with AOT, so perhaps it's a showstopper. Unless this would only use reflection on GodotSharp side to run proper source generators...

Thoughts?

[Delsin-Yu]

One way to implement an AOT-friendly serializer could be the following:

In GodotSharp Assembly

[AttributeUsage(AttributeTargets.Field | AttributeTargets.Property)]
public class ExportCustomAttribute(Type serializerType) : Attribute;

In User Code

public record MyDataModel(
    string Name, 
    string Description, 
    Vector2 VectorData, 
    DateTime[] Dates
);

public partial class MyNode : Node
{
    [ExportCustom(typeof(MyDataModelSerializer))] private MyDataModel _myModel;
}

public static class MyDataModelSerializer
{
    public static Error Deserialize(Variant serializedData, out MyDataModel dataModel)
    {
        // Implementation
    }

    public static Error Serialize(MyDataModel dataModel, out Variant serializedData)
    {
        // Implementation
    }
}

Generated by the Source Generator

// MyNode_ScriptSerialization.generated.cs
partial class MyNode
{
    protected override void SaveGodotObjectData(GodotSerializationInfo info)
    {
        base.SaveGodotObjectData(info);
        
        if (MyDataModelSerializer.Serialize(this.@_myModel, out var _myModel_serialized) == Error.Ok)
        {
            info.AddProperty(PropertyName.@_myModel, _myModel_serialized);
        }
    }

    protected override void RestoreGodotObjectData(GodotSerializationInfo info)
    {
        base.RestoreGodotObjectData(info);

        if (info.TryGetProperty(PropertyName.@_myModel, out var _value__myModel) 
            && MyDataModelSerializer.Deserialize(_value__myModel, out var _myModel_deserialized) == Error.Ok)
        {
            this.@_myModel = _myModel_deserialized;
        }
    }
}

[Delsin-Yu]

But I'm more curious about how to make these customized values appear in the inspector.

[tehKaiN]

That's basically what I was thinking about, but I think that defining serializer per-class might be more desirable, because otherwise it would add in a lot of noise if there are lots of properties requiring it.

As for inspector, I think that for now this functionality could be limited so that if Godot doesn't know how to display the field, then just skip it in inspector or show some kind of placeholder. Or perhaps there could be another attribute which makes the field serializable but not exposed in inspector, akin to Unity's [SerializeField]. Perhaps later the system could be expanded with similarly-defined method(s) responsible for building/handling the inspector UI.

[Delsin-Yu]

The Godot Dev Team is currently working on implementing godot-struct, which I think might be related to this topic. If you are interested, you can join the discussion. I saw a member working on C# support lately.