On Friday, February 02, 2018 09:40:52 Steven Schveighoffer via Digitalmars-
d-learn wrote:
> std.file.read returns a void[].
> I didn't see one that returns a ubyte[], and using the readText version
> is going to validate the text I think (which may not be desired). It
> really depends on the use case of the OP, but his original code was
> working with ubyte[] without validation, so I suggested the void[]
> return with cast.

readText calls std.utf.validate, which makes some sense if char, wchar, and
dchar are supposed to be UTF-8, UTF-16, and UTF-32 respectively, but then we
turn around and end up validating Unicode all over the place thanks to how
the range API works with "narrow" strings, making the validation kind of

Regardless, if what you want is ubyte[], then there's no reason to be
calling readText rather than read.

> It's a shame, actually, that ubyte[] isn't returned from read. I
> remember discussions at some point to change it, but that was shot down
> for some reason.

I can never remember what the reasons are for using void[] instead of
ubyte[]. I think that maybe it was argued at one point that having a
parameter be void[] made more sense, because it then can accept any array
type, but that argument doesn't hold for something returning void[]. It's
just a bunch of bytes, so I would have thought that ubyte[] would make more
sense. But I can't remember the arguments now, and without thinking through
it a bit, I'm not sure whether changing read to return ubyte[] would break
code or not. I don't _think_ so, since you have to cast from void[] to do
anything, and ubyte[] will implicitly convert to void[], but there may be
something that I'm missing that would make such a change a breaking change.
But the fact that it's void[] instead of ubyte[], means that it can't be
used in @safe code without using @trusted even if all you want is ubyte[].

- Jonathan M Davis

Reply via email to