How to implement a general high performance type conversion? without box and unbox, without reflection

[dczuo]

TTo Cast<TFrom, TTo>(TFrom source)
{
    // Support value type and reference type
    // Support implicit type conversion at runtime
    // Support explicit type conversion at runtime
}

Cast<int, int>(1);
Cast<int, int?>(2);
Cast<int?, int>((int?)1);

Cast<int, long>(1);
Cast<int, long?>(1);

Cast<long, int>(1L);
Cast<long, int?>(1L);

Cast<string, string>("a");

[Clockwork-Muse]

There isn't a way to do casts in the general case, because stuff like Cast<DateTime, HttpClient> is nonsense. So generally you know the types you're going to write at design time, and will be compiled without reflection. Even some of your examples have a similar issue: what's the problem with Cast<long, int>?
Generics also prevent many instances of boxing, so that likely isn't a concern in this case either.

You should be able to take a reference to essentially that as a conversion function in some callsites. Compare the various key/value selector functions throughout LINQ, which are doing exactly that.

[c-ohle]

@dczuo hi, good question as this is suboptimal implemented in NET 7.

I found the following solution: First, it needs a static TypeHelper template class that does nothing else to provide an ID, like a TypeCode, for all possible (number) types. The static constructor is only called once per type and is therefore not time-critical.

Now a Cast<,> template function can use these IDs to select the conversion. Implemented as in my example, it works for all system number types in both directions without boxing. In release, checked with BenchmarkDotNet, the Cast<,> function versions are then perfectly inlined.

This way it needs only one function for all cast's in difference to the NET7 implementation where every number type has a own subset of conversion template functions, where it neeads for functions like CreateTruncating two calls and inline is not always possible.

[Clockwork-Muse]

... You don't need the helper function, since generic specialization means you can implement per pair of types and that will be selected instead.

This way it needs only one function for all cast's in difference to the NET7 implementation where every number type has a own subset of conversion template functions, where it neeads for functions like CreateTruncating two calls and inline is not always possible.

Well yeah.
A conversion long -> int is (potentially) lossy, and programmers should be required to think about how they want their code to behave in such situations.

[c-ohle]

@Clockwork-Muse

generic specialization means you can implement per pair of types

This is right and works well for simple casts in the function.
But for any reasons it gives problems with inline by calling template functions from there.
After lot of trials I found this as workaround.

The ID approach with a little bit system behind, allows to reduce the necessary cast versions using "dummy templates" as trick. For the simple system number types for example from 400 to 16. Inclusive the truncating, saturating and checked versions to 48.