Expose ElementType and KeyType on JsonTypeInfo metadata.

[krwq]

public class partial JsonTypeInfo
{
    public Type? KeyType { get; } // relevant for JsonTypeInfoKind.Dictionary
    public Type? ElementType { get; } // relevant for JsonTypeInfoKind.Enumerable/Dictionary
}

These APIs are useful for querying the model, i.e.: generating docs, schema. It's not exactly trivial to implement them but we already store this data internally.

cc: @captainsafia

[ghost]

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

Issue Details

---

public class partial JsonTypeInfo
{
    public Type KeyType { get; } // relevant for JsonTypeInfoKind.Dictionary
    public Type ElementType { get; } // relevant for JsonTypeInfoKind.Enumerable/Dictionary
}

These APIs are useful for querying the model, i.e.: generating docs, schema. It's not exactly trivial to implement them but we already store this data internally.

cc: @captainsafia

Author:	krwq
Assignees:	-
Labels:	api-suggestion, area-System.Text.Json
Milestone:	-

[krwq]

consider how this interacts with custom element converters and element polymorphic serialization

[eiriktsarpalis]

Should these be nullable?

[eiriktsarpalis]

@captainsafia is this blocking you for .NET 8? We're moving it to Future if not.

[captainsafia]

@eiriktsarpalis It's no longer blocking for .NET 8 so it's sufficient to move it back to Future.

[bartonjs]

Video

Looks good as proposed.

public partial class JsonTypeInfo
{
    public Type? KeyType { get; } // relevant for JsonTypeInfoKind.Dictionary
    public Type? ElementType { get; } // relevant for JsonTypeInfoKind.Enumerable/Dictionary
}

[Neme12]

I don't have much knowledge about this area, but I wanted to ask anyway: shouldn't those properties return JsonTypeInfo? That's what I would expect if I saw those properties.

[Neme12]

Also, given the previous API review about TypeName... in that case, it was decided that rather than having nullable properties (like ElementType etc), those would be methods instead that would throw if called on the wrong type. @terrajobst mentioned that is better because it would be stupid if someone checked that the type is an array but would then have to check if the ElementType is null anyway after having checked that it's an array. Is there a reason why the consideration is different here?

Maybe the same argument applies here as well, because people will check whether the JsonTypeInfoKind is Dictionary or Enumerable anyway before getting the KeyType or ElementType?

[eiriktsarpalis]

shouldn't those properties return JsonTypeInfo?

No. The simple reason is that resolving the JsonTypeInfo for each of the element types and key types is delayed and happens only after the instance has been made read-only and its caches are being configured. We want these properties to be consistent regardless of what the serializer is doing under the hood.

Maybe the same argument applies here as well, because people will check whether the JsonTypeInfoKind is Dictionary or Enumerable anyway before getting the KeyType or ElementType?

The current behavior is consistent with the other public APIs on JsonTypeInfo. We only throw in property setters where the kind doesn't match.

[Neme12]

If it's locally consistent, then I understand. Although now I'm confused when you said:

We only throw in property setters where the kind doesn't match.

Isn't this the same thing? The property would throw if the kind doesn't match (disregarding the fact that properties shouldn't throw at all, and if it needs to, it should be a method instead. But you said there's prior art for this).

[eiriktsarpalis]

We only throw in property setters where the kind doesn't match.

Isn't this the same thing? The property would throw if the kind doesn't match.

There are no setters in the new properties.