N-bit sized int and floating point types [Feature-Request]

[hamarb123]

I propose we should be able to have N-bit sized int and floating point types.
Here is how it could work:

Obviously we already have the following:

• int 1 / uint 1 (bool)
• uint 8 (byte)
• int 8 (sbyte)
• uint 16, 32 and 64 (ushort, uint and ulong)
• int 16, 32 and 64 (short, int and long)
• float 32 (single)
• float 64 (double)

But what about the following:

• (u)int 2 (2 bits)
• (u)int 4 (4 bits)
• (u)int 128 (128 bits)
• (u)int 256 (256 bits)
• (u)int 2^n (2^n bits)
• (float 1 makes no sense but you could still add it)
• float 2 (2 bits)
• float 4 (4 bits)
• float 8 (8 bits)
• float 16 (16 bits)
• float 128 (128 bits)
• float 256 (256 bits)
• float 2^n (2^n bits)

The classes could be called the following:
For integers: intj where j is a power of 2
For unsigned integers: uintj where j is a power of 2
For floats: floatj where j is a power of 2
And there could be special names for floats between float8 and float256 ranging from quarter, half, single (already in there), double (already in there), quadruple, octuple

Why do I need this in my beloved c#?

1. Because it will give you more/less precise floats to use
2. It will give you more integers to use

Won't this ruin my IDE with millions of different type names?

1. No, if you make a maximum for the types (say 1024) or make it so that the IDE can have the ability to only show you some (say up to 1024) then it will not give you millions of types suggested

[CyrusNajmabadi]

Why do you need the C# language to change to accommodate this? You can just define your own int256 type and use that today already.

[CyrusNajmabadi]

Why do I need this in my beloved c#?

Because it will give you more/less precise floats to use
It will give you more integers to use

This not answering the 'why'. It's just restating the 'what'.

You haven't explained why this is actually needed. It's like me saying "i want channels in the language. why? because it would give me channels."

[hamarb123]

It would be faster and easier to use if it is a part of the actual c#

[hamarb123]

And there is no good floating point (bigger than double) libraries out there that do not just use System.Math which reduces it to double precision anyway

[CyrusNajmabadi]

It would be faster and easier to use if it is a part of the actual c#

Why? it would literally be the same to any end consumer. They would write "int128".

Or, in other words, what do you think the C# compiler could do here that you could not do yourself?

--

And there is no good floating point (bigger than double) libraries out there

You could write one :) It's unclear how the C# compiler would do this, or why C# would be responsible for this type.

Maybe you meant to suggest this new API on dotnet/corefx? This is the repo for the C# language. Types (like System.Int32/Float/Double/Boolean) belong in the BCL repos. Thanks!

[hamarb123]

Thanks, I will suggest it on there soon.

[aluanhaddad]

@CyrusNajmabadi but then you miss the opportunity to introduce a warm, and wonderfully fuzzy feeling, entirely cryptic, language-wide alias.

Come on, this might be our best and only shot at getting manifest long long int syntax into the language.

Think of the possibilities

ref readonly long long int value = ref x;

[hamarb123]

I think the type should be a part of the .NET framework but the syntax be a part of c#.

[aluanhaddad]

@hamarb123 sorry, I was thinking of what the natural alias might be if it existed, by drawing inspiration from and poking fun at C++ (I do love C++ though). I was kidding.

[mikedn]

(u)int 2 (2 bits)
(u)int 4 (4 bits)
float 2 (2 bits)
float 4 (4 bits)

"Types" smaller than 8 bits are rather dubious. They can't be actual types since the runtime has no notion of bit sized type. You'll never be able to have something like List<int2> and actually get a list of 2 bit elements, in the best case you'd get a list of 8 bit elements.

[hamarb123]

It doesn't matter if it actually uses 8 bits because bool also uses 8 bits.

[mikedn]

It doesn't matter if it actually uses 8 bits because bool also uses 8 bits.

bool isn't about size, it's about meaning. The Boolean data type that has 2 values - true and false, that is the return type of relational operators, that supports certain Boolean specific operations etc. People don't use bool because it's 1 bit or 8 bit or 32 bit, they use it for its meaning.

But small types such as int2 are primarily useful to reduce storage size. If you're telling me that an array of int2 is in fact an array of byte then it's quite likely that I'll create my own Int2Array (and I actually did that once) that does what is supposed to do. Pretty much the same way people create types like BitArray when a bool array won't do.

[ufcpp]

This can be done without a new language syntax. It only needs an analyzer:
https://github.com/ufcpp/BitFields
https://github.com/ufcpp/BitFields/blob/master/experimental/GenericBits/Bits.cs
https://github.com/ufcpp/BitFields/tree/master/experimental/TypeClassBits

[yaakov-h]

int2, int4 and so on sound like they would better be expressed via #105.

[MkazemAkhgary]

No, if you make a maximum for the types (say 1024) ...

2^1024? that's a very large number. I doubt anyone would need such a number. its sounds like a XY problem.

bringing on wolfram alpha to call 2^256 (for fun)

that was 78 decimal digits. let alone 2^1024 which is 309 decimal digits!

[fanoI]

The types int1, int2, int4 and so on are really similar to my proposal of bitfields: #465 or to this #457.

It can be OK to have int1 to be really 8 bit when used in this way:

int1 oneBit = 1; // I want a "restricted" range integer, its only valid values are 0 and 1, the actual used memory is 1 Byte

this can be accomplished with an analyzer as @ufcpp was saying but when you do this:

int1[] arr = new int1[8]; // I expect this to occupy exactly 8 bit --> 1 Byte, not 64 bit!

or this:

struct myDouble
{
    int1 sign;
    int11 exp;
    int52 mantissa;
}

myDouble x = Unsafe.As(aDouble); // 'x' should be the same size of double!

To accomplish these array bit / bitfield no CLR change is needed, an analogous compile transformation of when a fixed buffer is used in a struct can be made, the struct myDouble is changed to this:

struct myDouble 
{
      private long __compiler_mangled_name_m_value;

     public  int sign 
    {
                        set => set_field_value(__compiler_mangled_name_m_value, 0, value) 
                        get => get_field_value(__compiler_mangled_name_m_value, 0)
      };
   
    public int exp 
    {
                        set => set_field_value(__compiler_mangled_name_m_value, 1, 12, value) 
                        get => get_field_value(__compiler_mangled_name_m_value, 1, 12)
    };

    public long mantissa {
                       set => set_field_value(__compiler_mangled_name_m_value, 13, 64, value) 
                       get => get_field_value(__compiler_mangled_name_m_value, 13, 64)
    };
}

I'm instead unsure of the usefulness of float1, float2, float4... float16 yes it used in some GPU programming... but in my work in the embedded sector ever seen something to need a float4, well is really difficult to see a float used there really... only int (sometimes smaller than 8 byte) and string are used.

[aaronfranke]

Most of the types in the original post are rather arbitrary and the main benefit of adding them would be for the sake of including more types, which I don't think is a good enough reason.

Possible real-world use cases that I can think of (feel free to copy this to the original post):

Int128

• Native size for storing an IPv6 address (very relevant today)

• Packing two 64-bit or four 32-bit integers or floats into a single value

• Precise time-keeping. Unix time, in nanoseconds, will overflow in the year 2242 if it's stored in a signed 64-bit integer. This one is less relevant for now, but it would break ABI if someone developed a function with 64-bit integers and changed them to 128-bit later.

This is partly a joke, but we could make the type alias longer since it's bigger than long

Int4 (nybble, or a half of a byte)

• Minimum number of (unsigned) digits required for storing one digit of decimal. Useful for BCD.

• A smaller type than byte for when you just need to store a few possibilities. Likely most useful in sets where you can pack nybbles into bytes or ints.

I would personally use Int4 / nybble in my code, so +1 from me.

Also: Float sizes below 16-bit half-precision make no sense at all. Even at half-precision you can only store 3 decimal digits reliably. If you aim for millimeter-precision, that means a half-precision float can't get much bigger than 1.0 without issues.

[tannergooding]

I think there are three things that the compiler can do here, that a user-defined type cannot do itself.

However, I think one doesn't matter for user defined types and the other two are better answered by broader language features.

• The compiler, for primitive types, can emit the dedicated IL instructions for that primitive type
  • It already does this for all types, except for IntPtr and UIntPtr
  • This doesn't make a difference for non-primitive types and the JIT should reliably inline small operator calls
• The compiler can provide a keyword that makes it easy to use (i.e. float vs System.Single, int vs System.Int32, bool vs System.Boolean, etc).
  • This can be "solved" on a per-file basis, today, via using alias = type;
  • There have been multiple proposals for global type-aliases in C#. Another .NET language (F#) already provides them
• The compiler can have recognized types respect the checked/unchecked contextual keywords and will emit the appropriate overflow/underflow detection logic (or lack-there-of)
  • This is probably best handled by a language feature allowing the user to declare both checked and unchecked overloads of an operator. Then, a user can have their own custom Int128 that obeys the necessary rules

[fanoI]

Types smaller that bytes are not only used for BCD in my field a lot of devices "pack" their diagnostic in a byte each of them being a different diagnostic status, devices that gives you I/O ports for example one that has 32 input "pack" all in a int32 and any bit again is the status of a port.

The difficult part (maybe) would be on size of these types... when used as normal variable can be simply seen have size 1 byte but when in a struct / array this is not true anymore: an struct with array with 8 int1 should occupy 4 bytes.

Some examples:

uint1 a; // 8 byte
a = 0; // OK
a = 9; // Error only 0 and 1 are valid
uint1[] array = new uint[8]; // 8 byte non 64!

struct test {
   int4 a;
   int4 b;
};

var c = new test(); // 8 byte

sadly not having the possibility to do not have bit arrays / bitfields will force me to use C for those tasks.

[sgf]

request too,
like C/C++ Bit Fields https://docs.microsoft.com/en-us/cpp/c-language/c-bit-fields?view=vs-2019
https://docs.microsoft.com/en-us/cpp/cpp/cpp-bit-fields?view=vs-2019
this is a very useful.
im parse the IP or TCP Header. thats many Bit-Filed in there.
but its hard use C# define that now.
One Way is use shifting operation in Property getter setter.
But the code is hard to read.
but If c# have this feature, then it will become simple.