-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[API Proposal]: Add System.Text.Json built-in support for more numeric types #87994
Comments
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis Issue DetailsBackground and motivationSystem.Text.Json does not currently have built-in support for API Proposalnamespace System.Text.Json.Serialization.Metadata;
public partial class JsonMetadataServices
{
public static JsonConverter<Int128> Int128Converter { get; }
public static JsonConverter<UInt128> UInt128Converter { get; }
public static JsonConverter<Half> HalfConverter { get; }
public static JsonConverter<BigInteger> BigIntegerConverter { get; }
} API UsageThe Alternative DesignsNo response RisksAdding built-in support for new types risks regressing code size for apps that use both reflection and trimming such as Blazor. If folks think this is unacceptable, we might consider making these opt-in specifically for reflection, requiring users to manually touch the relevant converters: var options = new JsonSerializerOptions { Converters = { JsonMetadataServices.BigIntegerConverter } }; Although it goes without saying this would introduce inconsistent behavior between the two serializers.
|
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis Issue DetailsBackground and motivationSystem.Text.Json does not currently have built-in support for API Proposalnamespace System.Text.Json.Serialization.Metadata;
public partial class JsonMetadataServices
{
public static JsonConverter<Int128> Int128Converter { get; }
public static JsonConverter<UInt128> UInt128Converter { get; }
public static JsonConverter<Half> HalfConverter { get; }
public static JsonConverter<BigInteger> BigIntegerConverter { get; }
} API UsageThe Alternative DesignsNo response RisksAdding built-in support for new types risks regressing code size for apps that use both reflection and trimming such as Blazor. If folks think this is unacceptable, we might consider making these opt-in specifically for reflection, requiring users to manually touch the relevant converters: var options = new JsonSerializerOptions { Converters = { JsonMetadataServices.BigIntegerConverter } }; Although it goes without saying this would introduce inconsistent behavior between the two serializers.
|
More of a side question, but out of curiosity:
Why is that the case? I get that they're more advanced and specific APIs (in fact they're in a different namespace too), but why make them entirely not visible? I've found myself using them in a few cases, namely when writing custom converters. It's pretty handy to be able to get some specific built-in converters in those cases and then build your own custom converter on top of them, using composition. Would it make sense to consider making that type not hidden? 🤔 |
The short answer is that these served as proxy APIs back when contract customization wasn't available. The plan is to eventually have the source generator retarget contract customization APIs only and obsolete |
Punting |
Looks good as proposed. There was discussion to inspire a future change of accepting things based on the new numeric interfaces, but that's not for this issue. There was also a question of whether nint/nuint should be included, and the answer was 'no'. namespace System.Text.Json.Serialization.Metadata;
public partial class JsonMetadataServices
{
public static JsonConverter<Int128> Int128Converter { get; }
public static JsonConverter<UInt128> UInt128Converter { get; }
public static JsonConverter<Half> HalfConverter { get; }
} |
Background and motivation
System.Text.Json does not currently have built-in support for
Int128
/UInt128
andHalf
.API Proposal
API Usage
The
JsonMetadataServices
APIs are markedEditorBrowsable.Never
and are only intended for use by the source generator.Alternative Designs
Note that this proposes adding numeric type support on the converter level only and not on the
Utf8JsonWriter
/Utf8JsonReader
types or the DOM types. Since the underlying types do not have support for large numbers representable inInt128
orBigInteger
, we need to make use of other primitives. Examples of this can be found in this PR. Deserialization without incurring allocation also necessitates making this change.Risks
Adding built-in support for new types risks regressing code size for apps that use both reflection and trimming such as Blazor. If folks think this is unacceptable, we might consider making these opt-in specifically for reflection, requiring users to manually touch the relevant converters:
Although it goes without saying this would introduce inconsistent behavior between the two serializers.
Related to #86442
The text was updated successfully, but these errors were encountered: