[API Proposal]: Add JsonElement.ValueEquals(JsonElement)

[bill-poole]

Background and motivation

The System.Text.Json.JsonElement struct currently provides ValueEquals overloads for comparing the value of a JsonElement with a string (string, ReadOnlySpan<char> or ReadOnlySpan<byte>) representation of another JsonElement instance. However, if we want to compare two JsonElement instances, then this requires the following, which requires heap allocations and UTF-8 decoding.

jsonElement1.ValueEquals(jsonElement2.GetString());

It would be presumably much more efficient to be able to do:

jsonElement1.ValueEquals(jsonElement2);

API Proposal

namespace System.Text.Json;

public readonly struct JsonElement
{
    public bool ValueEquals(JsonElement other);
}

API Usage

// Compare jsonElement1 with jsonElement2
Console.WriteLine($"Values are equal: {jsonElement1.ValueEquals(jsonElement2)}");

Alternative Designs

No response

Risks

No response

[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.

[gregsdennis]

I have this as an extension in Json.More.Net.

var isEqual = elt1.IsEquivalentTo(elt2);

The code is here if you want to inspect.

[bill-poole]

Thanks @gregsdennis!

Your implementation still allocates though if the two JsonElement instances are JsonValueKind.String, JsonValueKind.Array or JsonValueKind.Object. I'm hoping a JsonElement.ValueEquals(JsonElement) overload would be allocation-free.

Also, comparing two JsonElement instances of type JsonValueKind.Number by parsing them both into Decimal instances is lossy if the two numbers have more decimal places than supported by the System.Decimal type.

[gregsdennis]

Also, comparing two JsonElement instances of type JsonValueKind.Number by parsing them both into Decimal instances is lossy if the two numbers have more decimal places than supported by the System.Decimal type.

This is true regardless of what .Net numeric type you use. It's an inherent consequence of a limited practical numeric space vs JSON's unlimited theoretical numeric space.

I chose decimal because I think my clients would prefer the extra precision over the extra range of double.

[bill-poole]

This is true regardless of what .Net numeric type you use.

Yes, but I would imagine a JsonElement.ValueEquals(JsonElement) overload would compare the numbers as strings, rather than converting them into a binary floating point type with limited precision/range.

[gregsdennis]

Yeah, that doesn't work, either: #97490.

4.0 and 4 are both valid JSON representations of the same value, but a string comparison doesn't work.

[bill-poole]

But isn't that the current behavior of JsonElement.ValueEquals(String), JsonElement.ValueEquals(ReadOnlySpan<char>) and JsonElement.ValueEquals(ReadOnlySpan<byte>)? I looked at their implementations and they don't deserialize then compare, they just compare the strings.

I would therefore propose that JsonElement.ValueEquals(JsonElement) would behave the exact same way. i.e., jsonElement1.ValueEquals(jsonElement2) would do exactly the same thing as jsonElement1.ValueEquals(jsonElement2.GetString()), but without the unnecessary allocation/decode.

[eiriktsarpalis]

Duplicate of #33388. Note that this has already been implemented in .NET 8 for JsonNode via the JsonNode.DeepEquals method.

[gregsdennis]

@eiriktsarpalis I think the ability to do this without allocation on JsonElement would be valuable. I don't think this is the same as that issue you linked.