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
