These are chat archives for rust-lang/rust

26th
Feb 2018
Yonggang Luo
@lygstate
Feb 26 2018 02:44
ARMv5TE
doesllvm support for
Hayden Pope
@TheStilbruch
Feb 26 2018 17:22
Hey guys like most rust noobs I’m having some trouble with borrowing
What would be the best way to impliment this function?
//TODO: Add error stuff here
fn get_name(stream: &mut TcpStream) -> Option<String> {
    let mut writer = BufWriter::new(stream);
    let mut reader = BufReader::new(stream);

    writer.write(&[0]).unwrap();

    let mut name_buf = String::new();
    reader.read_line(&mut name_buf);

    Some(name_buf)
}
Right now I’m getting an error because the BufWriter and BufReader new functions are taking ownership of stream
But I can’t use a reference because stream is already a reference
Joshua Liebow-Feeser
@joshlf
Feb 26 2018 18:26

@TheStilbruch It looks like you only use writer at the beginning, so you should be able to just construct the BufWriter and use it as a one-off like this:

rust

oops, like this:
BufWriter::new(stream).write(&[0]).unwrap()
That way, the BufWriter won't live beyond the end of the line
Ingvar Stepanyan
@RReverser
Feb 26 2018 18:33
Alternatively, if you want to keep both (in cases you'll both read and write from TCP socket later), you can just pass references to constructors
References of TcpStream implement Read / Write as well, so BufReader::new(&stream) and BufWriter::new(&stream) work
Hayden Pope
@TheStilbruch
Feb 26 2018 18:54
@RReverser I tried to do that, but because stream itself is a reference in that context, I end up passing a &&TcpStream which doesn’t work. I’ll just use your solution @joshlf
Actually @joshlf, when I do that, the value of stream gets moved and I can no longer use it
   --> src/main.rs:101:20
    |
98  |     BufWriter::new(stream).write(&[0]).unwrap();
    |                    ------ value moved here
...
101 |     BufReader::new(stream).read_to_string(&mut name_buf).unwrap();
    |                    ^^^^^^ value used here after move
    |
    = note: move occurs because `stream` has type `&mut std::net::TcpStream`, which does not implement the `Copy` trait
Ingvar Stepanyan
@RReverser
Feb 26 2018 18:59
It's because you are using &mut as the error says
And not immutable &
Joshua Liebow-Feeser
@joshlf
Feb 26 2018 18:59
Try changing the signature of the function to take an immutable reference?
Ingvar Stepanyan
@RReverser
Feb 26 2018 18:59
If you accept &TcpStream in function, BufReader::new(stream) and BufWriter::new(stream) should just work as currently written
Hayden Pope
@TheStilbruch
Feb 26 2018 19:01
That’s weird. Why don’t I need a mutable reference? Am I not making changes to the stream?
Ingvar Stepanyan
@RReverser
Feb 26 2018 19:01
No, you're not changing memory, you are just writing to it
Stream itself is still the same, so this is safe to expose and do with immutable reference
And you're not reading and writing to the same data, so there can be no race condition between them either
Dylan DPC
@Dylan-DPC
Feb 26 2018 20:22
What's the best thing to do when your function returns a Result<..> and the function can return either a io Error or a serde_json Error?
was thinking of creating a custom error enum that wraps both but is there a better way?
Michal 'vorner' Vaner
@vorner
Feb 26 2018 20:29
@Dylan-DPC There are crates that help you create these kinds of error enums/wrappers. Like error-chain or failure.
Dylan DPC
@Dylan-DPC
Feb 26 2018 20:29
ah yes thank you.
But i was wondering if it would be overkill :P
Michal 'vorner' Vaner
@vorner
Feb 26 2018 20:31
It depends on what you want to do. But every time I start writing a „little program for this“, I pull in failure, log, env-logger and structopt and don't worry, usually. If you're creating a library, you might want to think more about it.
Dylan DPC
@Dylan-DPC
Feb 26 2018 20:41
Agreed. but right now I just need it in one place but I can't rule out using it in several places in future. I'll stick to using failure then. Thanks :)
Michal 'vorner' Vaner
@vorner
Feb 26 2018 20:44
One thing with failure, though. failure::Error isn't for free. If you'll return a lot of errors, you probably want to define (with the help of failure) your own enum, instead of that one. But in the usual case, failure::Error is just fine, especially if errors mean terminating the program or so.
Dylan DPC
@Dylan-DPC
Feb 26 2018 20:44
ah ok
Zakarum
@omni-viral
Feb 26 2018 21:50
How do you request feature like serde from another crate if your crate has serde as optional dependecy (hence implicit feature)?