--- Comment #9 from 2010-08-04 09:23:45 PDT ---
(In reply to comment #5)
> any array operation which copies a block to another copies the flags from the
> original array block.  So the NO_SCAN flag should persist.  If it doesn't,
> that's a bug (looking at it, dup is the only function that doesn't copy the
> block attributes, I'll address this on the mailing list).

Concatenating arrays doesn't preserve the bit either. And if the user allocates
the void[], the NO_SCAN bit won't be set anyway. The user must remember to
allocate a ubyte[] array to get it right. How many users will even understand
why? (Also if you copy one array into another, flags won't be preserved. If you
allocate the void[] with C-malloc, lifetime.d won't do the right thing either.)

Let me repeat: the only reason why you want to use void[] here is because
void[] implicitly converts to any other array type.

But doing that is bogus anyway. If you convert it to an int[], you implicitly
assume the data stored on the disk is in the same endian as your machine's. If
it's an array of struct, you assume there are no padding issues (or further
byte order issues). If it's a char[], you assume it's valid utf-8.

No really, there should be specialized functions for proper I/O with certain
types. In no case should the user be encouraged to do the false thing.

void[] encourages to do 2 false things: 1. allocating the incorrect type, and
2. reading/writing data in a machine specific format.

I think it's a good thing to remind the user of 2. by forcing him to explicitly
cast the array. Yes, dear user, you ARE reinterpret casting your data to a
bunch of bytes!

I guess Andrei will remove the usage of void[] anyway because of his beloved
Java subset of D. void[] would allow aliasing pointers with integers, which is
a no-no in SafeD.

> But we can forgo all this stuff if we add a template parameter to read, so you
> can specify exactly the type you want.  If you know your file is a bunch of
> int's, you could do:

I guess nothing can stop the devs from killing Phobos with even more template
bloat. Your function call signature forgets anything about endians, though.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to