Why isn't there a `std::fs::read<T>()` function?

libs
1

Currently in Rust's std there are 2 functions that read directly the content of a file:

fn read<P: AsRef<Path>>(path: P) -> Result<Vec<u8>>

and

fn read_to_string<P: AsRef<Path>>(path: P) -> Result<String>

the question that I ask myself is, why isn't there a trait (e.g. FromRead / Readable, ...) that could allow to do this:

fn read<P: AsRef<Path>, T: FromRead>(path: P) -> Result<T>

Was that ever thought when designing std::fs ? If so, what are the arguments against it ?

2

It's not usually a good idea to tightly couple a serialization format to a type. What would the format be? Just something ad-hoc decided by each implementor of FromRead? Doesn't sound like a good idea. Based on

fn read<P: AsRef<Path>, T: FromRead>(path: P) -> Result<T>

it looks like you want a way to deserialize an entire file into a type, which definitely calls for a real de/serialization library.

On the other hand, something much more narrowly scoped, like a counterpart to FromStr that can be used to parse numbers and similar simple values from a Read is something I've missed at times.

3 Likes
3

Yes, something like read_by_lines(path) -> Result<Vec<T>> (where T is something like (usize, usize, usize)) to read the lines of Advent of Code-style problems would be very nice :wink: .

4

So, is that comma separated values? Tab separated? 3 binary values in big endian? Little endian? Or maybe hex in ASCII separated by arbitrary whitespace?

There isn't one obvious choice, so it shouldn't go in std.

5 Likes
5

While I agree parsing is too complex for std, one thing i would have prefered is having FromStr return on success both the value and the length of the matched portion, sometimes you just want to write a quick csv parser and the std FromStr impl on integers and floats is kinda useless for that, since they require the input string to be only what you are parsing and nothing else.

3 Likes
6

Well, it's actually what std::fs::read_to_string does. You could also argue that the std is doing similar things like parsing for Paths or Pattern.

If there is std::fs::read and std::fs::read_to_string both exists, why is it too complex to include a more generic option in the std ?

7

I don't agree on that. The user can always impl a trait for a type that doesn't make sens. Tho, I don't think that this mean that these traits should not exist in the std

(tho, I do agree that impl this on (usize, usize, usize) is a bad idea if it's what you meant)

8

The existing functions read a whole file either as bytes or as utf8 string. Bytes means no parsing at all, utf8 only requires validation, no transformation.

Most types are smaller than a file, unless the type represents some complex serializable format which can take up a whole file (e.g. an XML node tree). Having a file that contains a just a single datum, e.g. one u32, rarely makes sense, and even in that case the question would be how that one value is encoded. 4 bytes big/little/native endian? As ascii decimals? LEB128? etc.

Such traits are also non-trivial. serde's Deserialize is frequently used for structured data, but for binary message formats things like zerocopy's FromBytes may be more appropriate. And there are many other parsers out there.

5 Likes