Open up metadata infrastructure of System.Text.Json

[NinoFloris]

Today STJ does a lot of introspection like any other serializer to create fast getter/setters, find matching constructors and other things like it.

What would be very helpful — to provide better tools for custom converter writers — is to make public the internal code that handles logic like constructor matching, visible properties (shadowed members etc).

As an example, idiomatic F# records don't have an empty default constructor, writing code to match a constructor to the properties that were read is fairly finicky (and frankly tedious), especially if you'd want this to match STJ behavior exactly.

Another example that benefits from having more of this infra be public is OData like types where there is a typed object that also contains one dictionary property named Properties that stores all the unknown/dynamic props.

This means taking control over serializing potentially 'any' type, to keep a cache of all names and values, if unknown add it to the Properties dictionary, finally write this all into the object, either via fast setters, or via a matching constructor, preferably taking into account property visibility too.

I write from experience, this is also no fun in Newtonsoft where I similarly miss these apis.

It must be easier to harness metadata infrastructure STJ uses itself like ReflectionMemberAccessor, logic for finding a matching constructor etcetera. In my opinion this should be part of the public api of a good serializer.

[NinoFloris]

Related seems to be this comment from @layomia #2202 (comment)

[steveharter]

This overlaps a bit with #36785. Currently evaluating 5.0 plan.

[steveharter]

Moving to Future; will address when we have a single story for metadata and improved object\collection converters.

[eiriktsarpalis]

Closing in favor of #63686.