DIP: add Bit Fields

[Richard (Rikki) Andrew Cattermole]

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.