pattern check null first!

[DickBaker]

many of the syntaxes shown at Pattern matching overview
exhibit null checks way down the skip-chain, but imho that is not ideal as any previous “is” casts have to conduct their own null check [i.e. repeat such null guard checks]. IMHO the docs should persuade devs to place the null check as the first switch arm s.t. all subsequent emits will then KNOW the source object is NOT NULL to avoid excess code (per normal NRT behaviour)
It should not be left to any JIT/Prod-opt to shuffle test order.

the docs should also advise perf improvement to sequence individual tests s.t. number of comparisons is minimised [subject to logic], i.e. normally consider the frequent path before the rare unless those rare outliers can be checked first so remaining frequent cases can be handled by the discard catch-all.

BTW I originally post this on VS/C# repo Pattern matching overview but Jared Parsons recommended re-posting here instead.

[333fred]

Let me see if I'm understanding your point correctly; for this example, you're suggesting to move the null branch first?

public decimal CalculateDiscount(Order order) =>
    order switch
    {
        { Items: > 10, Cost: > 1000.00m } => 0.10m,
        { Items: > 5, Cost: > 500.00m } => 0.05m,
        { Cost: > 250.00m } => 0.02m,
        null => throw new ArgumentNullException(nameof(order), "Can't calculate discount on null order"),
        var someObject => 0m,
    };

If that's the case, then I have good news for you: you don't have to reorder anything here. Switch statements and expressions already handle this. The underlying logic is somewhat complicated (involving topological graph sorting), but the gist of it is: if it's possible to avoid checking something twice, we won't check it twice. A property pattern, like { Items: > 10, Cost: > 1000.00m }, includes an implicit null check of the input object. If that check fails, it goes straight to the null case, no further checking required. You can see how this code is actually structured here.

[DickBaker]

good news indeed and thanks for the sharplab.io expose that nails it ! We all agree that low-level tactics best handled by silicon [Einstein apparently said "Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.” so please close this #8251

[siegfriedpammer]

It should not be left to any JIT/Prod-opt to shuffle test order.

I think it should very well be left to the C# compiler to produce optimal code for patterns by reordering null checks that would happen implicitly anyway (like in property patterns). The developer should be able to focus on readability, maintainability and the requirements of the domain and not have to think about these things.

[DickBaker]

one more explained/documented/fixed; thanks Team !