Missing TypeCode for Half, Int128, UInt128?

[msedi]

I know that the Half, Int128, etc. have not been part of the original type system, but are there any plans to add them to the TypeCode enum?

Its just a question, originally I was needing them to create generic math. I have to dig a bit if I can resolve it now since the static interface and the "INumeric" methods exist now.

[Joe4evr]

are there any plans to add them to the TypeCode enum?

Likely never. Firstly, there may still be many consumers (even indirectly) relying on the fact that TypeCode hasn't expanded in two decades (even though I don't think it was ever guaranteed to never expand), so adding new values now could have a much larger impact than you think.

Secondly, what TypeCode was originally designed for seems like a mistake in modern .NET development. It'd be better if new code doesn't use it at all.

[Joe4evr]

@SetTrend This is the energy you're giving off.

[SetTrend]

@Joe4evr:   Let's not get off-topic.

Sure, there are people creating Settings database tables with a single row and 300⁺⁺ nullable columns, mainly null. And whenever a new application setting is implemented, they are migrating their database. They refrain from normalizing databases.

I prefer the more versatile, dynamic approach.

[tannergooding]

There are no plans to version TypeCode or IConvertible in the future.

Developers should use features like where T : INumber<T> and then T.CreateChecked, T.CreateSaturating, and T.CreateTruncating where possible instead.

Similarly, if they need to do a type specific behavior and specialize, the recommendation is to use if (typeof(T) == typeof(...)) or if (obj is ... instance) (replacing ... with the concrete type they're specializing for).

---

If you look in source.dot.net , I'm wondering why MS hasn't come up with as better solution. Obviously they like to write a lot of code ;-)

First, a lot of this code existed prior to features like generic math. But more importantly, this isn't the kind of code that can or should be shared generically because what you need to do (especially to keep it performant) is unique per type. We do simplify internal implementations where it is possible/relevant.

In the case of your code, you're reading a different number of bytes per T, so the shape itself is one that the BCL would likely not expose; instead we would require it return the number of bytes read as an additional output.

This is notably also why TBinaryInteger.ReadLittleEndian reads the entire span and treats the span as a single two's complement number, because when doing such operations generically, you need to support say int which might always write 4-bytes being able to read something like long which always writes 8-bytes even if the value is something like 0.

lack for constraint support (which can create runtime exceptions only, I cannot check it beforehand) and it seems that I cannot limit the method doing this:

.NET generics are not C++ templates, they need to persist in metadata and follow some ABI contract that can be understood at JIT compile time.

This means you can't just write arbitrary code and expect things to work and only fail if something mismatches. You need to have some kind of common "contract" (i.e. the constraint) against which calls can be emitted so it knows how to resolve say ReadLittleEndian.

The lack of creating a new type, the new constraint is too limited, and if it doesn't fit you always have to go with the Activator and MakeGenericType which slows down things tremendously.

Activator.CreateInstance is relatively fast, especially in recent releases.

But, there's also a simple solution to this problem as you can define some interface ICreatable<T> { static abstract T Create(); } and have your types implement it. If you need it to work more like a factory pattern, you have many other choices as well which allows you to then provide your own factory that creates instances of type T (just take in TFactor, T as the type parameters).

[msedi]

Developers should use features like where T : INumber and then T.CreateChecked, T.CreateSaturating, and T.CreateTruncating where possible instead.

I agree that things have changed recently and a lot of things are getting better with static abstract interfaces.

First, a lot of this code existed prior to features like generic math. But more importantly, this isn't the kind of code that can or should be shared generically because what you need to do (especially to keep it performant) is unique per type. We do simplify internal implementations where it is possible/relevant.

Also here I agree, I have the same implementations as you do for different data types, but the lack of constraining T to some very specific type is a big problem. For example the MKL can only do float and double, but there is not chance to limit it to these two, right? I could constrain it maybe to INumber<float..double> but this means I can use everything that is an INumber<float>, but I only can only deal with float/double array, so this opens the door for other problems. Am I right?

In the case of your code, you're reading a different number of bytes per T, so the shape itself is one that the BCL would likely not expose; instead we would require it return the number of bytes read as an additional output.

This is notably also why TBinaryInteger.ReadLittleEndian reads the entire span and treats the span as a single two's complement number, because when doing such operations generically, you need to support say int which might always write 4-bytes being able to read something like long which always writes 8-bytes even if the value is something like 0.
I'm not sure if I got this. What is wrong with public static T ReadLittleEndian<T>(ReadOnlySpan<byte> source). Sure, I could also live with public static bool TryReadLittleEndian<T>(ReadOnlySpan<byte> source, out T result) but ultimately you can read

ReadLittleEndian<int> as ReadInt32LittleEndian and ReadLittleEndian<float> as ReadSingleLittleEndian

I can see no difference in this. Additionally when it comes to the length

public static uint ToUInt32(ReadOnlySpan<byte> value)

and it siblings, they already check the length. So I agree the BitConverter exists since .NET Framework 1.1 (I think), but there really is a whole lot of code that is truly repetitive. There are of course things that are different, but for the end user the problem is when you need to scale between different datatypes in your application, lets say for example there are conditions (data size of the input data) where you need to switch from double to float to half a better generic support without having to write each code path. I understand the situation in the BCL and in our product code we have the same troubles an implement the optimized code path invidually sometimes really going down to ASM. Also when using CUDA you need to adjust your code pathes also for every hardware, so I'm really aware of the problems. But when it comes to higher level programming things should resolve to easier code. I'm not sure if you DICOM. This standard has nowadays 30 different datatypes which translate to DateOnly, TimeOnly, DateTime, TimeTimeOffset, string in 6-7 different flavors, float, double float-string, double-string and so on, additionally with different endianness, dependent on their encoding, sometimes switching the encoding and/or endianness in the same stream from one item to the other. With a few tweaks of the BCL things are perfectly possible, but then a Half type is introduced by the BCL, the new type was not in a unit test before and suddenly everything breaks because there was no contraint that it has not been implemented before, sure there is an exception that the type is not supported, but I 1. wasn't tested since the test didn't know about it and 2. it is too dynamic to cover all possibilities. All this is causing a lot of pain and work on our side.

.NET generics are not C++ templates, they need to persist in metadata and follow some ABI contract that can be understood at JIT compile time.
Sure, which I like, because C++ templates have their own problems ;-) Nevertheless is the lack of constraining generics to some special type a problem of the metadata then?

Activator.CreateInstance is relatively fast, especially in recent releases.
I tried, but still our implementation seems to be better. I can try again, but the problem is that it is hard to tell when things have improved and when they have improved. It would be good if there would be some table that shows some performance trend for selected implementations/features/libraries/methods. I think the BCL already has benchmarks. Can they be tabulated and put somewhere so that the community can follow the trends and do some lookups there?

But, there's also a simple solution to this problem as you can define some interface ICreatable { static abstract T Create(); }
This does not always work since we don't always own the used libraries. Additionally, the problem with T is that you do not always have a T but a Type, then ou need to go with MakeGenericType, etc and then the performance gets down. I try to get around this as much as possible, but sometimes you have to. The last time I had to do it I want to expression trees and dynamic runtime comilation to improve performance.

Sorry for too much text ;-) I would sometimes prefer a discussion in personal because the topic is too complex to describe this in this limited environment.

[tannergooding]

The typical way to handle supporting just two types like float and double is to have just those two for a public signature and have them defer to an internal shared implementation that is where T : IBinaryFloatingPointIeee754<T>

This allows you to correctly express the supported set to the consumer without forcing you to duplicate code across all supported types.

You can optionally expose a generic overload as well, but it then needs to check that T is only one of the supported types (like Vector128<T> does)