http://d.puremagic.com/issues/show_bug.cgi?id=4572
Steven Schveighoffer <schvei...@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schvei...@yahoo.com --- Comment #5 from Steven Schveighoffer <schvei...@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: -------