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

Open
opened this issue Feb 11, 2018 · 4 comments

Projects
None yet
6 participants
Member

### danmosemsft commented Feb 11, 2018

 @hamarb123 commented on Fri Feb 09 2018 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 a j bit integer For unsigned integers: `uintj` where j is a power of 2 for a j bit unsigned integer For floats: `floatj` where j is a power of 2 for a j bit float And there could be special names for floats between `float8` and `float256` ranging from `quarter`, `half`, `single` (already in .NET), `double` (already in .NET), `quadruple`, `octuple` 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 There are no good floating point (bigger than double) libraries out there that do not just use System.Math which reduces it to double precision anyway Won't this ruin my IDE with millions of different type names? Not 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

Closed

Member

### eerhardt commented Feb 12, 2018

 Are there real world scenarios that require this? Especially the lower cases - 4-bit integer/float. We already have `BigInteger` which can grow to any size. So I don't think we'd need another `2^n` int.

Member

### tannergooding commented Feb 12, 2018

 I think there are real world scenarios for bitfields (which has a language proposal: dotnet/csharplang#465). I don't think there is any need to provide framework types for them. I think providing `Int128`/`UInt128` is reasonable. It is part of the fundamental types (and therefore has special handling) in the ABI (Application Binary Interface) for a number of modern platforms we support (ARM64, System V, etc). Likewise, `Half` (Float16) and `Quad` (Float128) types are in the same category (are listed as fundamental types in most modern ABI). Additionally, they are well-defined types in the IEEE 754:2008 spec (`Float16` is the smallest. Types above `Float128` are also defined, but via a mathematical model rather than as explicitly defined types. These larger types are allowed in 32-bit increments).

Open

Member

### tannergooding commented Jan 22, 2019

 dotnet/corefxlab#2635 tracks prototyping a `binary16` and `binary128` compatible type as well as a `BigFloat` type.

### sgf commented Jun 6, 2019 • edited

 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.