[Issue 4572] std.file.read return type

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4572



--- Comment #10 from Steven Schveighoffer <schveiguy at yahoo.com> 2010-08-04 10:31:17 PDT ---
(In reply to comment #9)
> (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.

Yes, that should be addressed too, thanks for pointing it out!

> 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.

You're splitting hairs here.  ubyte and void are both just as nebulous, it's
just that void[] requires you to cast to something before reading it.  It means
"I don't know what the type is."  ubyte means "this is an array of unsigned
bytes", which is somewhat as nebulous, and one could argue more useful.  But
wouldn't it be best to just ask for the type you wish?  What if you want to
read a utf-8 file, wouldn't it be better for file.read() to return a char[]?  I
think the template solution works best.

> If you
> allocate the void[] with C-malloc, lifetime.d won't do the right thing either.)

Who's allocating a void[] with c-malloc?  I thought std.file.read allocated the
data with gc_malloc?

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

Well, it's for consistency.  void[] does not implicitly convert to another
array type, rather another array type can implicitly convert to void[].  So as
far as returning void[], it forces you to cast, even if you expect the data to
be ubyte[].

> 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.

So?  Is one not allowed to assume the contents of a file are in a format they
expect?  Typically one inserts magic numbers or something similar in a fie to
ensure the file is correct, but I don't see why casting makes the user more
keenly aware that the file might be incorrect.

> 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!

And that is what a void[] return does... not sure what you are getting at here.

> 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.

hehe, I don't think you know how close Andrei and Java are.

> > 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:
> > 
> > std.file.read!(int)();
> 
> I guess nothing can stop the devs from killing Phobos with even more template
> bloat. Your function call signature forgets anything about endians, though.

All it does is apply a type to a common function's return.  Endianness is an
implementation issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------