July 05

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!

July 05

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

>

On Wednesday, 3 July 2024 at 19:02:59 UTC, Dave P. wrote:

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

This is a great idea. And then you can extract this as a type as well!

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

>

I see potential for some nice things here. For instance VRP:

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.

July 05

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

>

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

>

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.

Well, it would allow skipping the bounds check.

July 05

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

>

https://github.com/WalterBright/documents/blob/2ec9c5966dccc423a2c4c736a6783d77c255403a/bitfields.md

Adds introspection capabilities.

https://github.com/dlang/dmd/pull/16444

"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

20 hours ago

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

>

On Wednesday, 3 July 2024 at 19:02:59 UTC, Dave P. wrote:

>

Wouldn’t a more D-like syntax be to have the number of bits following the type instead of following the variable name? This would be more consistent with how D arrays are different than C arrays.

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

I like this. As for arrays it's much more readable than the C syntax.

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.

1 2 3
Next ›   Last »