Ideas for Numeric Types

[LupusInferni315]

I think that the numeric types should contain both the implicit and explicit conversion methods (if for no other reason than conversion by reflection), every other type in C# requires such methods to be implemented when you want conversion, which when needing to use reflection with conversion makes it much easier to do, with the exception of numeric types, if you wanted to convert numeric types as such you would have to hardcode each and very conversion between them which is at least 169 different possible conversions.

[DrkWzrd]

Have you read some documentation recently?

https://learn.microsoft.com/en-us/dotnet/standard/generics/math

[Joe4evr]

and every time I've seen someone bring something like it up, they always get told that no such thing exists nor ever will

The main reason for that is it required some significant support in the runtime to make lookup of static abstract members even possible, and historically Microsoft has been very adverse to versioning the CLR due to compatability (all Framework apps share the same runtime version that ships inside Windows, so it had to behave consistently for every app).

However, for the past few years that no longer holds, and the runtime has more liberties to add/change functionality like what's done to enable generic math. Mainly because with .NET Core (now simply .NET >= 5) multiple runtime versions exist independant of the OS and if developers are afraid of a future version making some behavioral break, they can package their app with the exact runtime version they know works and stay entirely independant of what other apps (and corresponding runtime versions, including 0 runtime installations) might be on a user's machine.

[LupusInferni315]

Generic math also provides conversion methods. Though, somewhat unintuitively, they are called Create*, e.g. CreateChecked.

That doesn't actually provide the functionality I was looking for, if it was I also could just use the Convert class for it. I was specifically referring to looking for operators via reflection, which every other type has to define in order to have the same functionality as what is built into the compiler for Numeric types, instead of being defined in the class itself.

[Joe4evr]

@LupusInferni315 Unfortunately, static abstract members don't mix very well with reflection today. #73658 #79331 (These are hopefully fixed for .NET 8.)

In the mean time, have you considered reducing your dependency on reflection instead?

[tannergooding]

The primitive types explicitly do not contain such operators as they are instead supported via IL opcodes instead. The primitive types are ultimately special and will always require some amount of special handling.

The operators they do "provide" are new in .NET 7 and are all explicitly implemented via the INumber<TSelf> and related interfaces that were exposed as part of generic math. implicit and explicit casting operators were not exposed as part of this for many reasons and there are no plans to support them in the future because such limitations exist (this gets into problems with "overload resolution", number of methods exposed, number of interfaces that would need to be implemented, etc).

Instead, the generic math interface provide CreateChecked, CreateSaturating, and CreateTruncating. These 3 APIs allow you to convert between various INumber<TSelf> types in a safe and reliable way and to cover the three types of overflow considerations that exist (throw/check, clamp/saturate, and wrap/truncate).

[LupusInferni315]

@LupusInferni315 Unfortunately, static abstract members don't mix very well with reflection today. #73658 #79331 (These are hopefully fixed for .NET 8.)

In the mean time, have you considered reducing your dependency on reflection instead?

Where does an implicit or explicit conversion get declared as abstract? I know that they're static, but static members are not a problem for reflection, and I usually only use reflection for attribute related tasks, I had a project where I needed to convert between 2 types and only one was definable generically.