6 ms·

Well actually you couldn't return an &str, because it would be dropped at the end of the read. You'd need to return either a String (and that would be a big mi

Well actually you couldn't return an &str, because it would be dropped at the end of the read. You'd need to return either a String (and that would be a big mistake) or a Vec of u8. Which I'm sure you'd also be unhappy with

yodelshady 6y ago
>It should be possible to write a wrapper that does "return the line" Is it, or not? What's the point of lifetimes if you can't manage that trivial outlives-the-creator task in literally every other language ever with them? Why would a String be a big mistake? You STILL think Rust is easy to learn?
- estebank 6y ago
  It is. The reason it is not in the stdlib is because it is a foot-gun. Quoting myself from elsewhere in this thread[1]: > Other languages aimed at ease of use will just allocate for you and give you the fully baked contents in a single fn call, but when you're writing code that 1) has to be called often enough where allocations can show up in your flame graphs or 2) the input is big enough that you can't realistically keep the entire thing in memory at once, you suddenly have to care about what the fn is doing internally. Making the default API for file interaction require you pass in your own buffer makes this explicit at the cost of some ease of use. [1]: https://news.ycombinator.com/item?id=23811980 https://news.ycombinator.com/item?id=23811980
  - jfkebwjsbx 6y ago
    It is not. A very useful function does not mean you have to use it in the hot path or for huge inputs.
    - estebank 6y ago
      >>>>It should be possible to write a wrapper that does "return the line" >>> Is it, or not? >> It is. > It is not. I'm arguing that you can write that function. What Misdicorl is saying is that it would be fn read_line_alloc(&self) -> Result<String> and not fn read_line_alloc(&self) -> Result<&str> because the &str would be an "use-after-free" situation, and Rust won't let you compile it. You need to allocate if you are reading from a file in order to be able to close (or seek) that file. yodelshady seems to be under the impression that this means the functionality they want (single method call that doesn't require passing in a buffer) can't be implemented. It can, it just needs to allocate, the same way that you need to explicitly allocate the buffer you pass into read_line. > A very useful function does not mean you have to use it in the hot path or for huge inputs. I'm also arguing against it being provided in the stdlib because Rust is big in avoiding "you're holding it wrong" kind of answers, by removing the possibility to hold it wrong. Reasonable people can disagree :) I've also found it annoying in the past. If Rust didn't have a design goal of giving programmers full control over the behavior of their code, there are several ergonomics changes that we could make to make it much easier to use, but alas, that is not the language we have and we work with what we can make ergonomic and easy to use.
      - steveklabnik 6y ago
        I will say that I agree with almost everything you’ve said on this thread, but we did add std::fs::{read,read_to_string} for files to have this convenience. Adding something for stdin would bring that up to parity.
        estebank 6y ago
        Somehow I missed/forgot about that addition to the stdlib. I understand why (as evidenced by the requests in this same thread), but it I'm sad it's another thing I have to look for in code reviews ^_^'
        e12e 6y ago
        Would that work with /dev/stdin on Linux ?
        steveklabnik 6y ago
        I’d imagine so.
      - jfkebwjsbx 6y ago
        > I'm also arguing against it being provided in the stdlib because Rust is big in avoiding "you're holding it wrong" kind of answers Even if it was true that Rust is big on that, such a function is not "holding it wrong", it is just a matter of convenience and development speed vs. performance. For the vast majority of code it does not matter whether you allocate a few times or not. The timing difference is in the noise. Let Rust be a convenient language rather than a PITA.
- Misdicorl 6y ago
  Making it return a string would be a mistake for the space rust wants to (first) play in: low level system development. Returning a String requires figuring out what encoding the string has and parsing the contents in that encoding. That's not trivial or cheap or sometimes even possible (not all byte combinations are valid in all encodings) compared to filling a vec of bytes. That said, it's probably worthwhile to expose the functionality since people would find it useful in a lot of cases
  - zozbot234 6y ago
    Returning a String is not necessarily a mistake; you could check for UTF-8 validity and error out if the line is not valid UTF-8 - and if you're providing a wrapper for "simple" uses, this might even be the right call. You're right that the general case involves outputing raw bytes, of course.
- Misdicorl 6y ago
  Re: lifetimes question. You can solve this in rust just like you can in every other language. By allocating memory in the function and returning the allocation. String, not &str, is what represents that behavior. &str is kind of a rust wart that only exists because it's so damn useful to provide static text strings in a binary. Every other usage is pretty questionable and should basically be ignored/changed imo
  - zozbot234 6y ago
    &str is hardly a 'wart'. It's basically a safe version of C++ string_view, and it (together with array slices, which &str is essentially a special case of) is a very good example of the sorts of features that are enabled by Rust's focus on memory safety and close-to-the-metal efficiency.
    - Misdicorl 6y ago
      Those &str use cases are just as easily handled by &String. Perhaps with some extra sugar to slice at a requested boundary.
      - dbaupp 6y ago
        &String cannot, by itself, handle a substring because it has to point to an (immutable) whole String struct in memory. Any extra syntax or types to package up subslice boundaries would almost certainly end up as something similar to &str, just with potentially different syntax and likely slower.
        Misdicorl 6y ago
        I think you are incorrect. Exposing a slice of a String as an &String should have no performance impact (pointer and length just like &str). The only thing that becomes interesting is whether you can expose a mutable string slice
        dbaupp 6y ago
- andrewflnr 6y ago
  I don't think anyone is saying Rust is easy to learn. They're saying the complexity is justified (mostly).
yodelshady 6y ago
On looking at my code that does file reads, and steveklabnik's suggestion - Vec<u8> makes reasonable sense. At least that way, if you want nice encodings you've got the same problem agnostic of where the "string" came from. Aka... a nice abstraction.

yodelshady 6y ago

>It should be possible to write a wrapper that does "return the line" Is it, or not? What's the point of lifetimes if you can't manage that trivial outlives-the-creator task in literally every other language ever with them? Why would a String be a big mistake? You STILL think Rust is easy to learn?

estebank 6y ago
It is. The reason it is not in the stdlib is because it is a foot-gun. Quoting myself from elsewhere in this thread[1]: > Other languages aimed at ease of use will just allocate for you and give you the fully baked contents in a single fn call, but when you're writing code that 1) has to be called often enough where allocations can show up in your flame graphs or 2) the input is big enough that you can't realistically keep the entire thing in memory at once, you suddenly have to care about what the fn is doing internally. Making the default API for file interaction require you pass in your own buffer makes this explicit at the cost of some ease of use. [1]: https://news.ycombinator.com/item?id=23811980 https://news.ycombinator.com/item?id=23811980
- jfkebwjsbx 6y ago
  It is not. A very useful function does not mean you have to use it in the hot path or for huge inputs.
  - estebank 6y ago
    >>>>It should be possible to write a wrapper that does "return the line" >>> Is it, or not? >> It is. > It is not. I'm arguing that you can write that function. What Misdicorl is saying is that it would be fn read_line_alloc(&self) -> Result<String> and not fn read_line_alloc(&self) -> Result<&str> because the &str would be an "use-after-free" situation, and Rust won't let you compile it. You need to allocate if you are reading from a file in order to be able to close (or seek) that file. yodelshady seems to be under the impression that this means the functionality they want (single method call that doesn't require passing in a buffer) can't be implemented. It can, it just needs to allocate, the same way that you need to explicitly allocate the buffer you pass into read_line. > A very useful function does not mean you have to use it in the hot path or for huge inputs. I'm also arguing against it being provided in the stdlib because Rust is big in avoiding "you're holding it wrong" kind of answers, by removing the possibility to hold it wrong. Reasonable people can disagree :) I've also found it annoying in the past. If Rust didn't have a design goal of giving programmers full control over the behavior of their code, there are several ergonomics changes that we could make to make it much easier to use, but alas, that is not the language we have and we work with what we can make ergonomic and easy to use.
    - steveklabnik 6y ago
      I will say that I agree with almost everything you’ve said on this thread, but we did add std::fs::{read,read_to_string} for files to have this convenience. Adding something for stdin would bring that up to parity.
      - estebank 6y ago
        Somehow I missed/forgot about that addition to the stdlib. I understand why (as evidenced by the requests in this same thread), but it I'm sad it's another thing I have to look for in code reviews ^_^'
      - e12e 6y ago
        Would that work with /dev/stdin on Linux ?
        steveklabnik 6y ago
        I’d imagine so.
    - jfkebwjsbx 6y ago
      > I'm also arguing against it being provided in the stdlib because Rust is big in avoiding "you're holding it wrong" kind of answers Even if it was true that Rust is big on that, such a function is not "holding it wrong", it is just a matter of convenience and development speed vs. performance. For the vast majority of code it does not matter whether you allocate a few times or not. The timing difference is in the noise. Let Rust be a convenient language rather than a PITA.
Misdicorl 6y ago
Making it return a string would be a mistake for the space rust wants to (first) play in: low level system development. Returning a String requires figuring out what encoding the string has and parsing the contents in that encoding. That's not trivial or cheap or sometimes even possible (not all byte combinations are valid in all encodings) compared to filling a vec of bytes. That said, it's probably worthwhile to expose the functionality since people would find it useful in a lot of cases
- zozbot234 6y ago
  Returning a String is not necessarily a mistake; you could check for UTF-8 validity and error out if the line is not valid UTF-8 - and if you're providing a wrapper for "simple" uses, this might even be the right call. You're right that the general case involves outputing raw bytes, of course.
Misdicorl 6y ago
Re: lifetimes question. You can solve this in rust just like you can in every other language. By allocating memory in the function and returning the allocation. String, not &str, is what represents that behavior. &str is kind of a rust wart that only exists because it's so damn useful to provide static text strings in a binary. Every other usage is pretty questionable and should basically be ignored/changed imo
- zozbot234 6y ago
  &str is hardly a 'wart'. It's basically a safe version of C++ string_view, and it (together with array slices, which &str is essentially a special case of) is a very good example of the sorts of features that are enabled by Rust's focus on memory safety and close-to-the-metal efficiency.
  - Misdicorl 6y ago
    Those &str use cases are just as easily handled by &String. Perhaps with some extra sugar to slice at a requested boundary.
    - dbaupp 6y ago
      &String cannot, by itself, handle a substring because it has to point to an (immutable) whole String struct in memory. Any extra syntax or types to package up subslice boundaries would almost certainly end up as something similar to &str, just with potentially different syntax and likely slower.
      - Misdicorl 6y ago
        I think you are incorrect. Exposing a slice of a String as an &String should have no performance impact (pointer and length just like &str). The only thing that becomes interesting is whether you can expose a mutable string slice
        dbaupp 6y ago
andrewflnr 6y ago
I don't think anyone is saying Rust is easy to learn. They're saying the complexity is justified (mostly).

yodelshady 6y ago

On looking at my code that does file reads, and steveklabnik's suggestion - Vec<u8> makes reasonable sense. At least that way, if you want nice encodings you've got the same problem agnostic of where the "string" came from. Aka... a nice abstraction.