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

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 3 December 2015 at 14:24:52 UTC, Andrei Alexandrescu 
wrote:
> 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.

Doesn't matter as long as it's explicitly opt-in, and there's 
more than one way to do that. Template parameter flag, an 
alternative declaration such as unsafeBitfield, disallowing 
pointers but allowing a shallow wrapper around them 
("UnmanagedPtr" OSLT), etc.