Dictionary serialization

So now we have SerializeReference and serialized generics. Big fat elephant in the room is Dictionary<>. Is there any plans to add built-in support for dictionaries in 2020.2 or later?

With 2020.1 generics serialization it should probably be possible to implement your own SerializedDictionary class based on List (haven't tried it yet). But I think such a basic and commonly needed thing needs to be finally added.

 

I'll remind you of this thread from almost 3 months ago: https://forum.unity.com/threads/can-we-finally-get-a-built-in-serializable-dictionary.856183/
To be clear, I'm not surprised that nothing came out of it.

If we want to go on about the design of such an implementation, it should inherit .NET's built-in dictionary, not anything else. SerializableDictionary is Dictionary.

 

Actually, better yet:
• Lift the [Serializable] attribute requirement for serializing types. Where it's required is inconsistent anyway
• All types are composed of primitive data (character, number) at some level, so hierarchically serialize anything that follows the rules
• Provide a property drawer for the built-in dictionary
Power. In an ideal world, we'd be able to use custom-implemented properties and call serialized type methods in the inspector (e.g. `MyType.MyProperty { set => myData++; }`, `Dictionary.Add(...)`) which, although probably possible, is dream stuff.
I'd like to ask @JoshPeterson about the feasibility of this.

 

Eh please no, why do you think its inconsistent? How would you express a variable that you dont want to serialize in that case?

 

[NonSerialized], which btw seems to be required anyway when dealing with the new enter play mode options.

 

"First-class privileges" would be a better term. None of the primitive types (`string`, `char`, `int`, `float`, ...) and none of Unity's types (`GameObject`, `Transform`, ...) are marked with `[Serializable]`, yet they all get serialized. User types, meanwhile, require the attribute. This goes for both Unity's serializer and `BinaryFormatter`.

 

String, Char, Int, Single - the proper structs for string, char, int, float - are all marked with [Serializable]. The special case handling for Untiy's types doesn't happen with a binary formatter, and applies exactly to things deriving from UnityEngine.Object.

So you're wrong on both counts!

I get, though, that it's a bit silly that you have to stuff in two different attributes in two different places to make serialization happen. Afaik, [Serializable] doesn't do anything else than unlocking serialization (unless the compiler packs the thing differently), so it's perfectly possible to just not care and serialize everything you can.

If I were to do things from scratch, I'd decouple public/private and [SerializeField] - remove [NonSerialized] and require [SerializeField] on everything that's to be serialized. That'd be more straightforwards. But it's not like it's a big enough problem to refactor things over.

 

I've decompiled the relevant libraries and you're right. Apparently Visual Studio's "peek definition" ignores most attributes, because it only shows `[DefaultMember]` on `String` and nothing on the others.

Researching, I can only find that `[Serializable]` is required, but not why.

 

Because serialization is important enough to mark it explicitly. This way you instantly know instead of just guessing if an instance of the class is or is not serializeable.
A lot of things aren't serializable, a lot of things you don't want to serialize. It remains clear and instantly visible if you intend to serialize the thing you're looking at. And if you have anything in the serialization which doesn't have the attribute, you get an explicit error. As you should. Because explicit errors are great instead of silently failing or silently messing up the serialized data pool.

 

I'd prefer a "requires attribute" option to forcing it. There are text serializers (including the built-in XML serializer) that are fine without an attribute requirement, which makes it hard for me to see why a binary serializer would absolutely need it. While some stuff definitely can't be serialized, the vast majority can. There can always be intrinsics (e.g. the serializer refuses to serialize pointers because it knows that it's always asking for trouble).

 

But the serializer doesn't refuse to serialize pointers.

You only run the XmlSerizalizer explicitly, in Unity, you can run the binary serializer implicitly (Unity is running it for you). Maybe you would be okay an opaque way of doing this, but any serious project would instantly die on this.

And this is not even a Unity-related problem. It's a given behavior.

 

I'm referring to memory addresses. I think you're referring to the data that the pointer points to. In hindsight, the latter makes sense.

It's weird how rarely I see people pointing to settings as a way to solve debated behavior. It sound obvious, maybe that's why.

 

Unity has generally had a very, very hard "we don't make settings switches for core behaviour". That's probably smart - if you introduce settings like this every now and then, you quickly get millions of different engine configurations, and it becomes harder and harder to support everything.

 

We need a setting to ignore all settings!