System.Text.Json should support deserializing more collection types

[eiriktsarpalis]

STJ will today happily serialize any collection type that implements IEnumerable<T>, however things are less than ideal when it comes to deserialization support. While the serializer does include baked-in support for a number of common collection types, we still have a number of unsupported types such as frozen collections, ArraySegment<T> or IReadOnlySet<T>. Things become even more difficult when working with user-defined types: unless the type implements the conventions used by collection initializers users need to write their own custom converters.

This issue proposes that we extend generic support for collection type deserialization by detecting the following patterns (in order of preference):

1. Collection is mutable adhering to the conventions required by collection initializers or,
2. Collection declares a span factory via CollectionBuilderAttribute or,
3. Collection exposes a public constructor accepting a single IEnumerable<T> parameter (where the T must match the T of the implemented IEnumerable<T>).

I have prototyped an implementation of this approach both for reflection and source gen in the typeshape-csharp project. This should add OOTB support for multiple built-in types that aren't supported today, or should make it relatively straightforward to make changes to collections such that they are supported (e.g. by adding CollectinBuilderAttribute annotations). For popular types not conforming to any of these patterns, we should consider adding baked-in converters to support them.

Related Issues

• Add support for collection types with parameterless or IEnumerable<T> constructors. #80688
• STJ and Frozen collections #82642
• Unable to deserialize ArraySegment<int> with System.Text.Json.JsonSerializer.Deserialize #107783
• System.Text.Json cannot deserialize to IReadOnlySet #91875

cc @stephentoub @CyrusNajmabadi

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

[CyrusNajmabadi]

Hi hi. I see the mention. How can I help?

[eiriktsarpalis]

Was curious to get your thoughts on the proposed use of patterns (and their ordering) when determining a collection construction strategy.

[elgonzo]

How about inline arrays?

I also wonder what would happen if STJ requires a CollectionBuilderAttribute (CBA) for deserialization of inline arrays when (if?) the C# compiler eventually gets built-in support for collection expressions for inline arrays, and i am a bit concerned about that by virtue of STJ requiring CBA for deserializing inline arrays, a very convenient compile-time check of making sure that the collection expression is correctly sized will be again turned into a user-implemented runtime-check (as it is unfortunately currently the case with inline arrays) because the compiler will have to respect the CBA that is only there to satisfy STJ.