Using boxing ((int)(object)value) instead of pattern matching (value is int intValue) in number classes

[skrysmanski]

In the Create*() methods in the various number types you can see code like this (here: from Int32.CreateChecked):

int result;

if (typeof(TOther) == typeof(int))
{
    result = (int)(object)value;
}
else if (!TryConvertFromChecked(value, out result) && !TOther.TryConvertToChecked(value, out result))
{
    ThrowHelper.ThrowNotSupportedException();
}

return result;

I'm interested in this condition in line 3:

if (typeof(TOther) == typeof(int))
{
    result = (int)(object)value;
}

Wouldn't it be better to write it like this:

if (value is int intValue)
{
    result = intValue;
}

As far as I understand it, this would avoid the boxing of value in (int)(object)value.

However, since I'm seeing this pattern in a lot of places (especially in the TryConvertFromChecked methods), it would seem, I'm missing something here.

Why didn't the author use pattern matching here?

[huoyaoyuan]

The (ConcreteType)(object)genericVariable is a special sequence in generic context. It's specially understood by the JIT. The generic mechanism doesn't allow casting a variable typed with T to be casted to arbitrary destination type. The fake box instruction is to workaround the limitation. Even non-boxable type is also allowed with the special sequence (https://github.com/dotnet/runtime/blob/main/docs/design/features/byreflike-generics.md#special-il-sequences). With generic instantiation, no actual boxing will be performed by this special sequence.

Pattern matching actually generates more box instructions. See the example at https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBLANgHwAEAmARgFgAoQgBgAIBlACwEMoAHAGReADoAlAK4A7DNgC2MANxVCAZjok6AYToBvKnS2KFhFHQCyACgCU6zdoC+FrTZ11sow6QA8AFQB8Rt3QBuLXEEYEzsNSm0IhwAzOiN/QJgHAGcHJ18Q8MitMKyswgB2PxlMrOsSyIK6GmKIsoi7O3lUjENidy8feKCMiJzc7BijDABPdhgIKO8zAF5puhGxiaNHDBMe3L7c7Url0RMjCGAAKxgwVa7pO1qr7cLquzrtRoUVwzl27z8A7tCbrQHYhdknRcBBhABzEHrLKbLaKQq7Va4Gq5R5ZAFxb6JbApV7YaGRWFbSrYFGlP7wqpkuhoujPZqGFAfTpYglE7QYhbjSZuGZzLlLUEQtYU9l5BErfZC8H7ADyx1O5yx1Ou5QinNG3KmdFm801S0lBN6FIiO0lBwVZxMFxVVgplXu5TKliAA=

The current JIT is able to optimize both patterns, but optimization for pattern matching is less mature than the well-known special sequence.

Ideally, the pattern matching should be done on the type, not the variable. The ultimate solution is proposed at dotnet/csharplang#6308 (comment).

[huoyaoyuan]

https://sharplab.io/#v2:EYLgHgbALANALiAhgZwLYB8ACAmAjAWAChMAGAAgGUALRAJwAcAZRYAOgCUBXAOzgEtUAUwDcRTAGYyOMgGEiAbyJllZANoApPnADig7oNp8AxgAo4AT3qCA9gDMTfXgEonAXSUqJZR3DIBZXAAeABUAPhNgsgA3RAAbTkEnD2VFQhV071syExj4wW9kb15opLSMlOTyzwB2aNEy8oBfSvTMWpJ69OaGskrKjS1dfUNTCys7B2c3Sq8ff2wQ8MjchNL01KrM7LGbe2CnMgBeQ7IdiZ8XFpUNzZrsi5NrYAArQSM4JxWRK+VuzbayB1Kn8VH0egMdHoDMYzJZdpMPtMerNin5xIsItE4qtKjdynwsjlsfk+IVYtZuABzMixNZVPG3AEIpyxTpVEH4wlfApFXx8OnlBn/Wp8NlNH5Sdpisgc3o9fqaSHDGFnewXJGtSRzPxQDHLYkCshClQE7Zwib7I4nVUmclUy49dYS1q1Zm2imUpwmADyLzeHy+0q6EtNsPGewOx1O5rVUwlxvKTIeT1e70+xKDKllLsB0u6jSAA===

The .NET Framework JIT is able to optimize the box-unbox sequence, but can't optimize pattern matching.