These are chat archives for rust-lang/rust

5th
Apr 2018
Russell Cohen
@rcoh
Apr 05 2018 03:30
I want to override Ord for an Enum for 1 specific case while preserving the derived behavior for other cases. Is that possible?
To make things more concrete:
pub enum Value {
    Str(String),
    // Consider big int
    Int(i64),
    Float(OrderedFloat<f64>),
    None,
}
I want the ordering to come out sensibly when floats & ints are concerned
Russell Cohen
@rcoh
Apr 05 2018 03:39
eh nevermind I just implemented all the cases :-P
TatriX
@TatriX
Apr 05 2018 08:23

I have an Option<T> and I want to turn in into a Vec<T>, so I'll get either empty vec or 1-element vec. I do it like this:

let mut persons = signer.map_or(vec![], |person| vec![person]);

If there is a shorter way?

Michal 'vorner' Vaner
@vorner
Apr 05 2018 08:26
Option can be turned into an iterator over the 0 or 1 item and you can collect an iterator into a vector. So (out of memory, maybe subtly wrong) signer.into_iter().collect::<Vec<_>>()
Azriel Hoh
@azriel91
Apr 05 2018 08:38
@rcoh I was going to suggest rust-derivative but then Ord hasn't been implemented: mcarton/rust-derivative#3
Thought you may be interested anyway
Dylan DPC
@Dylan-DPC
Apr 05 2018 11:08
@mexus issue with bounds on the structs?
Denis
@mexus
Apr 05 2018 11:11
@Dylan-DPC no real issues afair, just a matter of a code cluttering
Dylan DPC
@Dylan-DPC
Apr 05 2018 11:12
i need the trait bounds for other purposes
Denis
@mexus
Apr 05 2018 11:14
it's fine then. just wanted to show it might work even without the bounds :) but if you need them it's a different story though
Dylan DPC
@Dylan-DPC
Apr 05 2018 11:17
though i'm considering rewriting this in a better way
Ingvar Stepanyan
@RReverser
Apr 05 2018 13:45

Option can be turned into an iterator over the 0 or 1 item and you can collect an iterator into a vector. So (out of memory, maybe subtly wrong) signer.into_iter().collect::<Vec<_>>()

Which, consequently, can be turned into Vec::from_iter(signer) (although you'll have to import FromIterator into scope)

apiraino
@apiraino
Apr 05 2018 13:58
Hello, again here - I'm in need for some tips about using async Futures
What I'd like to accomplish at the moment: have a listening TCP server (port: 6601) that gets some payload and then forwards this payload to another server (port:6600)
it compiles but I receive a warning:
warning: unused `tokio::prelude::future::AndThen` which must be used: futures do nothing unless polled
  --> src/main.rs:55:25
   |
55 | /                         TcpStream::connect(&addr2).and_then(|res2| {
56 | |                             println!("answer={:?}", res2);
57 | |                             // TODO: forward data to this socket
58 | |                             Ok(())
59 | |                         });
   | |___________________________^
   |
   = note: #[warn(unused_must_use)] on by default
basically I'm trying to understand the way that I can chain a Future result to another one.
Denis
@mexus
Apr 05 2018 14:08
and what do you want to do with the result of connect().and_then()... ?
if your answer is "nothing", then just spawn it
like you do with handle_conn
apiraino
@apiraino
Apr 05 2018 14:10
Hi Denis :) The result from the second Future is not important at the moment, or is it? Later on I can read the response of the server and forward the return code to the first socket
Denis
@mexus
Apr 05 2018 14:10
then for now you could probably simply spawn it away :)
apiraino
@apiraino
Apr 05 2018 14:12
can I add another tokio::spawn() statement or should I spawn the Future right after the definition (i.e. at line 38)?
Denis
@mexus
Apr 05 2018 14:13
i didn't quite get it
apiraino
@apiraino
Apr 05 2018 14:13
I know, i'm sorry. i'll try to explain better
Denis
@mexus
Apr 05 2018 14:13
where else would you like to spawn it if not right after the def?
apiraino
@apiraino
Apr 05 2018 14:14
I currently have a spawn at line 46. That's where the main Future is triggered
the other Future at line 34 (the connect), how should it be spawned?
example:
Denis
@mexus
Apr 05 2018 14:15
i'd go with tokio::spawn(connect(..).and_then(...)... )
apiraino
@apiraino
Apr 05 2018 14:17
oh interesting. I'll try your solution. My second solution however doesn't compile. Apparently I need to manage a Result
error[E0271]: type mismatch resolving `<tokio::prelude::future::AndThen<tokio::net::ConnectFuture, std::result::Result<(), std::io::Error>, [closure@src/main.rs:55:83: 59:26]> as tokio::prelude::Future>::Error == ()`
  --> src/main.rs:60:25
   |
60 |                         tokio::spawn(connect_to_dest);
   |                         ^^^^^^^^^^^^ expected struct `std::io::Error`, found ()
   |
   = note: expected type `std::io::Error`
              found type `()`
   = note: required by `tokio::spawn`
Denis
@mexus
Apr 05 2018 14:19
yes, you should map it to a unit
spawn expects both Item and Error of the provided future to be units (())
apiraino
@apiraino
Apr 05 2018 14:20
ok therefore add a map() and a map_err() combinators?
Denis
@mexus
Apr 05 2018 14:21
something like tokio::spawn(connect_to_dest.map_err(|e| prinltn!("Encountered an I/O error while connecting to {}: {}", addr2, e)))
i guess your Item is already a unit :)
edit: tokio::spawn(connect_to_dest.map_err(move |e| println!("Encountered an I/O error while connecting to {}: {}", addr2, e)));
apiraino
@apiraino
Apr 05 2018 14:23
ok, that compiles. Then I can move forward and implement more logic.
Can you help me understand the meaning of the move here?
that is map_err(move |err| {}) instead of map_err(|err| {})
Denis
@mexus
Apr 05 2018 14:25
it's because of addr2, it has to be moved inside the closure to be safely passed away
because addr2's lifespan is limited (it lives only until line 40)
apiraino
@apiraino
Apr 05 2018 14:25
ah ok it's move as in the "Rust way of moving ownership"
Denis
@mexus
Apr 05 2018 14:26
yep
apiraino
@apiraino
Apr 05 2018 14:26
it works, the socket on the second server is opened and then closed
crazy
now I'll try to forward the payload from the first connection to the second one
Denis
@mexus
Apr 05 2018 14:27
:+1:
apiraino
@apiraino
Apr 05 2018 14:27
I think it's enough dog food for now, thank you so much @mexus
see you tomorrow, I guess XD
Denis
@mexus
Apr 05 2018 14:28
you are welcome!