[Issue 4572] std.file.read return type

[d-bugmail at puremagic.com]

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


Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy at yahoo.com


--- Comment #5 from Steven Schveighoffer <schveiguy at yahoo.com> 2010-08-04 05:24:44 PDT ---
(In reply to comment #4)
> One can add that .dup-ing a void[] will make all the precaution in
> std.file.read of allocating the void[] with GC.BlkAttr.NO_SCAN useless. The
> dup'ed array won't have the NO_SCAN flag set. It really shows that void[] is
> not the natural type to use here.

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

I think the void[] type is more consistent than ubyte.

Consider two things.  First, a read where the array is provided by the caller. 
If this function is typed:

ubyte[] read(ubyte[] into);

then, you must cast your data to a ubyte[].  But void[] can be implicitly cast
to from anything, so void[] wins here.

Second, a write operation:

int write(ubyte[] from);

Again, cast is necessary where void[] would not require it.

To be sure std.file.read() could return a ubyte[], and unless you intend to
actually deal with it as a ubyte[], you need to cast to the type you need.  But
shouldn't it be consistent with other operations?

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)();

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