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

[Steven Schveighoffer via Digitalmars-d]

On 12/3/15 9:28 AM, Andrei Alexandrescu wrote:
> On 12/03/2015 07:45 AM, Steven Schveighoffer wrote:
>>
>> taggedPointer and taggedClassRef are GC safe (despite the incorrect
>> warning listed in the docs). Your proposed mechanism is not.
>
> It can be restricted to support what tagged* do.

This is a possibility. Allowing higher bit manipulation is no good for 
the GC. Allowing lower bit manipulation that extends past a single 
element is no good also. These restrictions are enforced at compile time 
by the tagged functions.

>
>> IMO, we should keep those and close your enhancement, it doesn't add
>> anything useful. Seems to me something that can break very easily.
>
> Please leave it open, thanks.

I of course would not close it, that is not my place.

>> Phobos should in no way support such egregious casts implicitly. Even in
>> @system code.
>>
>> Do you have any rationale to prefer arbitrary bitfield pointers over GC
>> safe ones?
>
> 1. The less restricted version offers use of high-order bits as well.

Again, this is not GC-safe. But another thing taggedPointer and 
taggedClassRef do (that I think your proposal does not) is restrict the 
lower bits that can be manipulated based on the alignment of the target 
type.


> If
> we don't support that, those who need it will do that in client code
> with the usual liabilities.

The usual liabilities aren't mitigated by the proposal. I was under the 
impression that D should allow error-prone code, but shouldn't promote it.

> 2. There's no reason for taggedPointer and taggedClassRef to exist. They
> should be integrated within bitfields.

One departure from bitfields for tagged* is that the API does not allow 
invalid pointer/bitfield specifications (the number of bits reserved for 
the pointer is implied from the pointer type and arch). Your proposal 
uses an assert to verify the bits from the pointer source are zero, 
allowing a possible corruption to occur if you compile with -release. 
The tagged* types prove at compile time that you will ALWAYS see zero 
bits there (because of alignment).

As long as bitfields follows the same rules and API, then I think it 
could potentially be merged. But I don't see a huge value in this, seems 
like an unnecessary code break.

-Steve