Should serialize avoid emitting metadata on types that are unsupported on deserialize?

[jozkee]

Today, we only emit metadata to reference types and we avoid doing it for value types, but there are a few reference types that are unsupported on deserialization, mostly because they have the special behavior of temporarily storing its elements on an enumerable.

An example of those types are:

• T[]
• ImmutableDictionary<TKey, TValue>

You cannot deserialize with preserve semantics into these types therefore they are unable to round trip.

public static void RoundTripArray()
{
    string[] words = new string[] { "apple", "banana", "cherry" };

    var opts = new JsonSerializerOptions
    {
        ReferenceHandling = ReferenceHandling.Preserve
    };

    string json = JsonSerializer.Serialize(words, opts);
    /* serialized words:
    {
        "$id": "1",
        "$values": [
            "apple",
            "banana",
            "cherry"
        ]
    }*/
    string[] wordsCopy = JsonSerializer.Deserialize<string[]>(json, opts);
}

Running above sample throws the following example on JsonSerializer.Deserialize:

Cannot parse a JSON object containing metadata properties like '$id' into an array or immutable collection type. Type 'System.String[]'.

Alternatively we can do one the following options to avoid the round-trip issue:

• Avoid emitting metadata for these unsupported types (as suggested in the title).
• Throw when an unsupported type is attempted to be serialized.
• On deserialize try to "eat up" or ignore the metadata semantics (but still validate that they are correctly formatted, as we do for struct objects?).

cc @ahsonkhan, @layomia, @steveharter

[jozkee]

This will be fixed on #2259 by doing the described behavior on bullet 1.

Avoid emitting metadata for the unsupported types.

If that is the desired behavior, we can close this when said PR gets merged and we add unit tests that ensure correct behavior.

[jozkee]

These cases (the ones in the description) are reference types, that someone could expect to work as any other reference type, hence we decided to keep the exception to make explicit that they are not supported and avoid misuses.

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of the experimental issue cleanup initiative we are currently trialing in a limited number of areas. Please share any feedback you might have in the linked issue.

This issue will now be closed since it had been marked no recent activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.