Why are void[] contents marked as having pointers?

[Walter Bright]

Vladimir Panteleev wrote:
> I just realized that by "performance" you might have meant memory
> leaks.

No, in this context I meant improving performance by not scanning the 
void[] memory for pointers.

> Well, sure, if you can say that my programs crashing every few
> hours due to running out of memory is a "performance" problem. I'm
> sorry to sound bitter, but this was the cause of much annoyance for
> my software's users. It took me to write a memory debugger to
> understand that no matter how much you chase void[]s with
> hasNoPointers, there will always be that one ~ which you overlooked.

I'm curious what form of data you have that always seem to look like 
valid pointers. There are a couple other options you can pursue - moving 
the gc pool to another location in the address space, or changing the 
alignment of your void[] data so it won't look like aligned pointers 
(the gc won't look for misaligned pointers).

Or just use ubyte[] instead.

> As much as I try to look from an objective perspective, I don't see
> how a memory leak (and memory leaks in D usually mean that NO memory
> is being freed, except for small lucky objects not having bogus
> pointers to them) is a problem less significant than an obscure case
> that involves allocating a void[], storing a pointer in it and losing
> all other references to the object.

Because one is an obvious failure, and the other will be memory 
corruption. Memory corruption is pernicious and awful.

> In fact, I just searched the D
> documentation and I couldn't find a statement saying whether void[]
> are scanned by the GC or not. Enter mr. D-newbie, who wants to write
> his own network/compression/file-copying/etc. library/program and
> stumbles upon void[], the seemingly perfect
> abstract-binary-data-container type for the job... (which is exactly
> what happened with yours truly).
> 
> P.S. Not trying to push my point of view, but just trying to offer
> some perspective from someone who has been bit by this design
> choice...

Hmm. Wouldn't compression data be naturally a ubyte[] type?