Pattern Matching Boxed Primitives Differs From Unboxed Primitive

[Cooksauce]

Description

Pattern matching exhibits surprising behavior when values are boxed long's.

Why is this behavior a bug?

I think this is a bug because 1L is 1 is pattern matched as true, while (object)1L is 1 is matched as false.

Why fix?

Pattern matching is very useful on loosely typed data. This kills some of the benefit because you have to type-check the target data in order to get intuitive results. More importantly, you have to know you have to type-check; otherwise, you silently get unexpected results.

---

Real use case

System.Data.Common.DbCommand cmd = ...some command
object? count = await cmd.ExecuteScalarAsync();

// Surprise - this will never be true b/c `count` will be a boxed `long`
if (count is 1)
{
    // do something
}

// This will be true, if count is actually the value `1` was actually returned
if (count is 1L)
{
    // do something
}

Reproduction Steps

    [Fact]
    public void Boxed_Pattern_Match_Should_Match_Unboxed()
    {
        long val = 1L;
        object valBoxed = 1L;

        Assert.True(val is 1);
        Assert.False(val is not 1);
        Assert.True(valBoxed is 1);  // fails
        Assert.False(valBoxed is not 1);  // fails
    }

Expected behavior

Boxed long should pattern match the same way unboxed long matches.

Actual behavior

Boxed long does not pattern match the same way unboxed long matches.

Regression?

unknown

Known Workarounds

Type check the value first, (e.g. count is long countLong && countLong is 1)

Configuration

• .NET Version: NET 8.0
• OS: macOS
• Arch: ARM64

Other information

No response

[huoyaoyuan]

This is a question related to C# language, not runtime behavior. C# compiles them into different checks.

The behavior is similar to == with a cast. longVariable == (long)1 will success, but (long)(object)longVariable == (long)(object)1 will throw.
In other words, the pattern is interpreted at the available type information of LHS. Literal 1 will be interpreted as (object)(int)1 when LHS is object.

Boxed long does not pattern match the same way unboxed long matches.

This can't happen. Once a number is boxed, it's impractical to try every possible type.

Type check the value first, (e.g. count is long countLong && countLong is 1)

You can also use count is 1L to provide a literal of long type to match with, like this:

https://github.com/dotnet/roslyn-analyzers/blob/5ed336762c6260a83ece35cd1f6749251452bad0/src/NetAnalyzers/Core/Microsoft.NetCore.Analyzers/Performance/UseSpanClearInsteadOfFill.cs#L100-L105

Note that this code manually traverses every numeric type it cares about. It's necessary to explicitly do so.