4 ms·

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.

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