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