On 23/04/2024 4:16 AM, Walter Bright wrote:
> In the very rare case of actually needing an exact layout, with 5 minutes of effort any layout can be duplicated with C bit fields. If that's too much effort, one can write explicit shift/mask code, and encapsulate it into a function. (Once the function is inlined, there is zero extra overhead for it.) Or one can use std.bitmanip to do that automatically.
> 
> Yes, we can add extra syntax and semantics to make this controllable by the user, but it's so rarely needed it's over-engineering.

It depends so heavily on what you are doing, as I'm sure you know.

If you work with file formats, IPC (sockets, pipes ext.), CPU flags for embedded devices, or performing instruction encoding for fun, you'll end up dealing with this stuff heavily enough that you want language support.

If all you need it for is some flags in process then of course it appears to be over-engineering.

I'm in the former group often enough that it is pretty uncomforting for me to see that this feature won't exist in those circumstances and this thread shows that I am not alone in this.

On 4/22/2024 10:28 AM, Richard (Rikki) Andrew Cattermole wrote:
> If you work with file formats, IPC (sockets, pipes ext.), CPU flags for embedded devices, or performing instruction encoding for fun, you'll end up dealing with this stuff heavily enough that you want language support.

std.bitmanip.bitfields are the appropriate solution for that.

BTW, the backend does a lot of instruction encoding :-)

I'd prefer it was written using bitfields, it would make the code more readable. I'm sure I wouldn't have any difficulty using C bitfields for it. I'm sure you wouldn't, either.

On 23/04/2024 12:38 PM, Walter Bright wrote:
> On 4/22/2024 10:28 AM, Richard (Rikki) Andrew Cattermole wrote:
>> If you work with file formats, IPC (sockets, pipes ext.), CPU flags for embedded devices, or performing instruction encoding for fun, you'll end up dealing with this stuff heavily enough that you want language support.
> 
> std.bitmanip.bitfields are the appropriate solution for that.

This is something I do not want brought over to PhobosV3.
Due to its reliance on CTFE, tooling cannot work with it.
Its a pretty horrible thing to use I've found.

I do not recommend using string mixins to introduce symbols that then get interacted with by the user.
Same with mixin templates (I actually need to check to see if it supports eponymous at some point, naming an instance gets you to a lot of cases without the downside of a string mixin).

Anything that uses string mixins to create symbols for a user to use, is likely to always cause usability issues for people.

Plus with this DIP, the equivalent functionality is in the language, why would we want to duplicate where people need to look for it and have to remember the difference between them in terms of syntax?

> BTW, the backend does a lot of instruction encoding :-)
> 
> I'd prefer it was written using bitfields, it would make the code more readable. I'm sure I wouldn't have any difficulty using C bitfields for it. I'm sure you wouldn't, either.

I used that as an example, although it would only really be of use when you're above a register in size.

Being able to cast straight to a ``ubyte[]`` and then send off to something else (or the reverse) is a mighty useful thing to have since the cast is free.

Both issues of defining LSB..MSB for multibyte along with introspection can be added later without a DIP. So this shouldn't hold it up, I'm giving push back because I know I'll be explaining all this at some point and I'd prefer to not have to.

On 4/22/24 18:16, Walter Bright wrote:
> 
> In the very rare case of actually needing an exact layout, with 5 minutes of effort any layout can be duplicated with C bit fields.

Well, if someone is not aware that a gun can shoot one's own foot, they might do it even if they very well know it is not good to hurt one's foot.

> If that's too much effort, one can write explicit shift/mask code, and encapsulate it into a function. (Once the function is inlined, there is zero extra overhead for it.) Or one can use std.bitmanip to do that automatically. 

I suppose you could match C bitfields with a string mixin too. Or the compiler could automatically generate a portable specification corresponding to the C bitfield layout.

> The preceding is true if one wants a specific layout.
> 
> But to algorithmically match what the associated C compiler does, that is more of a significant problem. It took me a while (with the help of Iain) to reverse-engineer it. This is a problem worth solving, and our implementation does solve it. For the user, it effortlessly resolves the issue of binary interoperability with C code.

Yes, I agree with this. However, there is a difference between having this feature and making it the _default representation_ of bit fields.

It's just about how to best expose that feature for the best overall ergonomics, including introspection.