Neat project: add pointer capability to std.bitmanip.bitfields

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 3 06:24:52 PST 2015


On 12/03/2015 06:13 AM, Vladimir Panteleev wrote:
> You said that "at the end of the day there's documentation". I would
> argue that at least in this case, it may not be enough. Consider, for
> example, a hypothetical user type "Pack", which takes a tuple/struct and
> automatically arranges the fields into a struct such that space is used
> optimally (e.g. all bools are clumped together into a bitfield, enums
> are only given as much bits as their .max needs, etc.). Pack only needs
> to know one property of each field: how many bits it really needs, and
> as such, it might elect to be agnostic of what a pointer is. If it uses
> std.bitmanip.bitfields as its backend, it will happily pack a pointer at
> its user's request, and the user will never see the pointer warning in
> Pack's documentation. And yes, although it's easy to point the finger at
> users and say "ha ha, it's your own fault, you did not RTFM", I think we
> should strive for better than that.

I understand how you feel but I really don't know what else to do, which 
makes the entire discussion somewhat theoretical. At the end of the day 
Pack must document its own behavior and its users should have some 
notion of its characteristics. If Pack wishes to disallow pointers that 
can be easily done with static introspection. If it doesn't have enough 
information, it's poorly designed - it can't just take any bits and 
shove them in any way. -- Andrei


More information about the Digitalmars-d mailing list