5 ms·

Partly personal preference in both what is readable and in how much you optimize caller convenience vs simple callee code. I think it's fine to just expect the

Partly personal preference in both what is readable and in how much you optimize caller convenience vs simple callee code. I think it's fine to just expect the caller to do the conversion. In fact, it's often automatic. (Eg if you have a PathBuf, then just sticking a & in front of it is sufficient to supply &Path via Deref<Target = Path>.) So I'd write this function as follows: fn read(path: &Path) -> io::Result<Vec<u8>> { let mut file = File::open(path)?; let mut bytes = Vec::new(); file.read_to_end(&mut bytes)?; Ok(bytes) } which I find readable. Comparing to another language...I haven't written Go in a while, but I think the rough equivalent would be: func Read(path *Path) ([]byte, error) { file, err := os.Open(path) if err != nil { return nil, err } slice, err := io.ReadAll(file) if err != nil { return nil, err } return slice, nil } (Maybe in this case you'd just return the io.ReadAll rather than doing an if, but I'm trying to use similar constructs. The ? is something you can use all throughout the function, not just at the end, so I tried to match that pattern.) [edited: I said there wasn't a io.ReadToEnd extracted from io.ReadFile in Go, but jatone pointed out it's called io.ReadAll.]

capableweb 5y ago
I don't know Rust but converting that code snippet of Go code you wrote to (non-idiomatic [wouldn't use upper-case characters, namespaces used doesn't actually exists]) Clojure: (defn Read [path] (io/ReadToEnd (os/Open path))) Now that's what I call readable!
- brundolf 5y ago
  Clojure is also a much higher-level language than Rust (and arguably Go too)
- scottlamb 5y ago
  You can chain calls in Rust. If read_to_end were written to allocate and return a fresh Vec, you could do this: File::open(path)?.read_to_end() but instead read_to_end is written to take a presupplied Vec so the caller has the option to reduce allocations.
- masklinn 5y ago
  > Now that's what I call readable! Unsurprisingly APIs can be more readable when you don't ponder why they're designed the way they are and completely ignore their purpose. The `read_to_end` API[0] was designed such that the buffer could be reused in order to avoid unnecessary allocations. There are helpers for common tasks, though people may not know or notice them. In the case of `Read::read_to_end`, it's called std::fs::read[1], which actually preallocates the vector based on file size internally so might be faster than hand-rolling `read_to_end`. So here's your code in Rust, for the last 3 years or so (since 1.26 was released): fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> { std::fs::read(path) } [0] and all of the Read trait in general [1] https://doc.rust-lang.org/std/fs/fn.read.html https://doc.rust-lang.org/std/fs/fn.read.html
jatone 5y ago
bytes, err := ioutil.ReadAll("path.txt") is the golang equivalent.
- deleted 5y ago
  [deleted]
- steveklabnik 5y ago
  To be clear you can write let bytes = std::fs::read(“path.txt”)?; If you’re trying to actually do this in real code. The example is how you’d write this function yourself, but if you’re just trying to Get It Done, it’s significantly easier than the example.
oxnrtr 5y ago
fun read(path: &Path): io.Result[Vec[UInt8] { var file = File.open(path).orReturnErr() var bytes = Vec.new() file.readToEnd(&mut bytes).orReturnErr() Ok(bytes) } would be good enough for me, tbh.
- yakubin 5y ago
  > File.open(path).orReturnErr() Method syntax is reserved for functions. There are no method syntax macros. Since a return in a function terminates execution of this function, and not its caller, your example would not work.
  - zozbot234 5y ago
    Right, so this should really be .orReturnErr , by analogy with .await . We just overload the dot symbol to mean both "method call" and "weird monadic stuff is happening here".
    - simon_o 5y ago
      Exactly. ! for macros was a mistake anyway, I guess that's why they stopped using it with await.
      - yakubin 5y ago
        It wasn't. Without "!" it isn't obvious that you cannot take a: let a: Result<u8, u8> = /* whatever *; let b = match a { Ok(v) => Ok(foo(v)), e => e, }; and transform it into: let a: Result<u8, u8> = /* whatever *; let b = a.map(foo); if "foo" is a macro. When you substitute "foo!" for all the "foo" above, it is obvious.
        simon_o 5y ago
        Perhaps macros shouldn't do things that aren't "obvious" then?
lenkite 5y ago
I never understood why Rust requires '&mut' while passing parameters. file.read_to_end(&mut bytes)?; `bytes` is already mutable. `read_to_end` is already declared as taking a `&mut Vec<u8>`. So why force every caller to do a `&mut` un-necessarily ?
- MathiasPius 5y ago
  It's so that a reader of the calling code can immediately reason about which calls might be mutating state. If you have 10 calls, all taking &bytes, any of which may or may not be mutating the data while others are merely reading it, it becomes very difficult to reason about. By being explicit about this, Rust becomes easier to read, but (slightly) harder to write.
  - zozbot234 5y ago
    Shared borrows and unique borrows also behave very differently in Rust. '&mut' for unique borrows is a bit of a misnomer, because passing some objects via a shared '&' reference might also mutate state 'indirectly' via internal mutability.
- masklinn 5y ago
  > So why force every caller to do a `&mut` un-necessarily ? Because it's not unnecessary? `bytes` is a `Vec`, not a `&mut Vec`, those are different things, and Rust generally avoids magically doing things under the covers. So it doesn't auto-ref (let alone auto-mut-ref) parameters, only subjects.

capableweb 5y ago

I don't know Rust but converting that code snippet of Go code you wrote to (non-idiomatic [wouldn't use upper-case characters, namespaces used doesn't actually exists]) Clojure: (defn Read [path] (io/ReadToEnd (os/Open path))) Now that's what I call readable!

brundolf 5y ago
Clojure is also a much higher-level language than Rust (and arguably Go too)
scottlamb 5y ago
You can chain calls in Rust. If read_to_end were written to allocate and return a fresh Vec, you could do this: File::open(path)?.read_to_end() but instead read_to_end is written to take a presupplied Vec so the caller has the option to reduce allocations.
masklinn 5y ago
> Now that's what I call readable! Unsurprisingly APIs can be more readable when you don't ponder why they're designed the way they are and completely ignore their purpose. The `read_to_end` API[0] was designed such that the buffer could be reused in order to avoid unnecessary allocations. There are helpers for common tasks, though people may not know or notice them. In the case of `Read::read_to_end`, it's called std::fs::read[1], which actually preallocates the vector based on file size internally so might be faster than hand-rolling `read_to_end`. So here's your code in Rust, for the last 3 years or so (since 1.26 was released): fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> { std::fs::read(path) } [0] and all of the Read trait in general [1] https://doc.rust-lang.org/std/fs/fn.read.html https://doc.rust-lang.org/std/fs/fn.read.html

jatone 5y ago

bytes, err := ioutil.ReadAll("path.txt") is the golang equivalent.

deleted 5y ago
[deleted]
steveklabnik 5y ago
To be clear you can write let bytes = std::fs::read(“path.txt”)?; If you’re trying to actually do this in real code. The example is how you’d write this function yourself, but if you’re just trying to Get It Done, it’s significantly easier than the example.

oxnrtr 5y ago

fun read(path: &Path): io.Result[Vec[UInt8] { var file = File.open(path).orReturnErr() var bytes = Vec.new() file.readToEnd(&mut bytes).orReturnErr() Ok(bytes) } would be good enough for me, tbh.

yakubin 5y ago
> File.open(path).orReturnErr() Method syntax is reserved for functions. There are no method syntax macros. Since a return in a function terminates execution of this function, and not its caller, your example would not work.
- zozbot234 5y ago
  Right, so this should really be .orReturnErr , by analogy with .await . We just overload the dot symbol to mean both "method call" and "weird monadic stuff is happening here".
  - simon_o 5y ago
    Exactly. ! for macros was a mistake anyway, I guess that's why they stopped using it with await.
    - yakubin 5y ago
      It wasn't. Without "!" it isn't obvious that you cannot take a: let a: Result<u8, u8> = /* whatever *; let b = match a { Ok(v) => Ok(foo(v)), e => e, }; and transform it into: let a: Result<u8, u8> = /* whatever *; let b = a.map(foo); if "foo" is a macro. When you substitute "foo!" for all the "foo" above, it is obvious.
      - simon_o 5y ago
        Perhaps macros shouldn't do things that aren't "obvious" then?

lenkite 5y ago

I never understood why Rust requires '&mut' while passing parameters. file.read_to_end(&mut bytes)?; `bytes` is already mutable. `read_to_end` is already declared as taking a `&mut Vec<u8>`. So why force every caller to do a `&mut` un-necessarily ?

MathiasPius 5y ago
It's so that a reader of the calling code can immediately reason about which calls might be mutating state. If you have 10 calls, all taking &bytes, any of which may or may not be mutating the data while others are merely reading it, it becomes very difficult to reason about. By being explicit about this, Rust becomes easier to read, but (slightly) harder to write.
- zozbot234 5y ago
  Shared borrows and unique borrows also behave very differently in Rust. '&mut' for unique borrows is a bit of a misnomer, because passing some objects via a shared '&' reference might also mutate state 'indirectly' via internal mutability.
masklinn 5y ago
> So why force every caller to do a `&mut` un-necessarily ? Because it's not unnecessary? `bytes` is a `Vec`, not a `&mut Vec`, those are different things, and Rust generally avoids magically doing things under the covers. So it doesn't auto-ref (let alone auto-mut-ref) parameters, only subjects.