On Thursday, 4 July 2024 at 18:34:00 UTC, Steven Schveighoffer wrote:

uint:4 value(){
   // return 200; // error
   return 7; // ok
}

Yes, super!
This would also allow us do define

alias uint:1 bool

and be sure assigning a value larger than 1 to be an error!

On Thursday, 4 July 2024 at 18:34:00 UTC, Steven Schveighoffer wrote:

struct Foo {
    uint:4 x;
    uint:5 y;
}

A weird restricted type. Didn't dmd used to have a bit type that was abandoned?

uint:4 value(){
   // return 200; // error
   return 7; // ok
}

int[16] arr;
arr[value()] == 5; // VRP makes this valid

Did you mean = 5? If so the assignment already compiles, so VRP would make no difference for that code.

On Friday, 5 July 2024 at 10:19:56 UTC, Nick Treleaven wrote:

Well, it would allow skipping the bounds check.

On Sunday, 5 May 2024 at 23:08:29 UTC, Walter Bright wrote:

"In practice, however, if one sticks to int, uint, long and ulong bitfields, they are laid out the same."

This has been proven false: https://forum.dlang.org/post/gsofogcdmcvrmcfxhusy@forum.dlang.org

I no longer agree that this is a good feature to add, at least with the deferral of specification to the incumbent C compiler.

-Steve

On Thursday, 4 July 2024 at 12:20:52 UTC, Dom DiSc wrote:

struct Foo {
    uint:4 x;
    uint:5 y;
}

What I dislike about this is that uint:4 and ushort:4 would be different types, but that makes no sense. The only way this would make sense to me is if uint were fixed and not an arbitrary type, but a more natural approach to D would be using a __traits trait or adding new keywords e.g. __bits and __ubits with them producing __bits(4).

To pack those in structs, we could be cheeky and extend the align concept with fractions. Alignment is in bytes, but two __bits(4) can be aligned so that they overlap, and align(0.5) could do that. Of course, the argument to align must be a multiple of 0.125 and be a power of 2. Or we just allow align(0.125) as a special exception to specify that __bits(n) fields of a struct are packed.

struct Foo {
    __bits(3) x;
    __bits(5) y;
}

There, x and y have different addresses and Foo.sizeof is 2.

struct Foo {
    align(0.125) __bits(3) x;
    align(0.125) __bits(5) y;
}

Here, x and y are stored in the same byte and Foo.sizeof is 1.

On Wednesday, 17 July 2024 at 03:24:28 UTC, Walter Bright wrote:

I would honestly love a bit type. Make today’s bool the bit type and re-introduce real booleans that interact with integer types similar to how pointer types do: You can cast pointers to integers and vice versa, but not implicitly. Conceptually, a bit is a number that’s 0 or 1. It’s e.g. ideal to represent numerical carry. bool could be an enum type with backing of a bit.

The wrong turn on the original bit type probably was the idea to be able to point to individual bits.

On Thursday, 18 July 2024 at 00:02:15 UTC, Quirin Schroll wrote:

Why? As pointers are 64bit, the highest three bits will never be used anyway (at least not for the next 20 years). Simply shift all pointers 3bits to the right and use the lower 3 bits to indicate the bitoffset.

So, it's easy to get the adress of a bit: its the byte-adress + the bitoffet, so simply all info in the pointer.

In addition make the length also bitlength, so we could define 2bit or 4bit types without any problem.

In the age of 64bit byte- or word-wise adressing makes no sense anymore.

On Thursday, 18 July 2024 at 08:52:35 UTC, Dom DiSc wrote:

This is a stupidly unreliable and highly system-dependant hack: https://stackoverflow.com/a/18426582
How will you make this work on 32-bit systems? How will you make this work on iOS—a 64-bit system where pointers are 32-bit? How will you make this work on systems with 64-bit pointers that have all of their bits reserved?

That will only work if they are aligned to 8-byte boundaries.