These are chat archives for rust-lang/rust

11th
May 2016
Danny Angelo Carminati Grein
@fungos
May 11 2016 00:18
hi
Richard Protasov
@rprotasov
May 11 2016 00:24
@fungos hola!
nishidy
@nishidy
May 11 2016 12:51
Hi, I'm new to Rust lang. Could you please see my short code of Rust and help me understand?
I just want to find a word in a string with regex like this.
let mut t2: String = "123abc".to_string();
let t = "123";

t2.push_str(t);

let re = Regex::new(r"[0-9]*([a-z]*)[0-9]*").unwrap();

if let Some(x) = re.captures(&t2).unwrap().at(1) {
    println!("The result is {}",x);
    // t2.clear(); // This is not allowed.
}
t2.clear();
// */
Then, clear it when I find the word. But it is not allowed because it is borrowed by re.captures().
Erik Hedvall
@Ogeon
May 11 2016 12:56
I suppose capture returns references to t2 instead of copying the matching sections. That means that t2 needs to be borrowed for the whole if block, and can therefore not also be changed.
nishidy
@nishidy
May 11 2016 13:00
wait
Erik Hedvall
@Ogeon
May 11 2016 13:01
Looking at the documentation show that this is indeed the case. The 't lifetime parameter connects the input string with the output Captures, meaning that the input will stay borrowed as long as the output is in use. Captures, in turn, passes this on to the output of at, meaning that the input to captures will stay borrowed as long as the output of at is in use.
I hope this makes sense...
nishidy
@nishidy
May 11 2016 13:05
Ok, let me check it. thanks
Erik Hedvall
@Ogeon
May 11 2016 13:07
You're welcome. Just let me know if you have any more questions
nishidy
@nishidy
May 11 2016 13:08
Great.
Erik Hedvall
@Ogeon
May 11 2016 13:09
(not that I'm the only one answering)
nishidy
@nishidy
May 11 2016 13:09
Sure
nishidy
@nishidy
May 11 2016 13:26
Ok, probably I understand it correctly in that the immutable reference to t2 is borrowed by captures() and the output is passed to at() and then the result is bound to x. The scope of this x is in the if {}, so t2 is not allowed to change until x is not released.
As the doc says, the lifetime 'tis for t2 (for the input of captures()) and x (for the output of at()) in this case.
If it is correct, how could I clear t2 when I can find word in a string?
Erik Hedvall
@Ogeon
May 11 2016 13:35
That is correct. A simple solution is to return a boolean value from the if that indicates if it's to be cleared or not:
let mut t2: String = "123abc".to_string();
let t = "123";

t2.push_str(t);

let re = Regex::new(r"[0-9]*([a-z]*)[0-9]*").unwrap();

let should_clear = if let Some(x) = re.captures(&t2).unwrap().at(1) {
    println!("The result is {}",x);
    true
} else {
    false
};

if should_clear {
    t2.clear();
}
There may be more elegant or robust ways, but this is what I could think of off the top of my head.
nishidy
@nishidy
May 11 2016 14:02
Oh, I forgot that if can return value in some languages.
Erik Hedvall
@Ogeon
May 11 2016 14:03
if, match and freestanding blocks are expressions in Rust :smile:
Zakarum
@omni-viral
May 11 2016 14:04
Not many laguages allow that. But with borrow-checking this feature come in handy
Maybe someday I will be able to terminate the lifetime of binding by calling meme::drop or another moving funtion that isn't return bound values
Erik Hedvall
@Ogeon
May 11 2016 14:12

meme::drop

Is that for meme dropping? :wink2:

(sorry)
Ogeon @Ogeon don't know why he didn't just let it pass
retep998 @retep998 drops bunnies on top of @Ogeon
Ogeon @Ogeon accepts his new, bunny covered life
Zakarum
@omni-viral
May 11 2016 16:29
Cool story
nishidy
@nishidy
May 11 2016 23:39
Next question. We need to use unwrap() method many times since the returned value is contained by some type, say Option(it's trait? Can we say that is monad or context?) In Haskell, it will end gracefully during several binds in a row when one of them fails. However, this unwrap() just panic when nothing in there. Rust will support this method chains gracefully?
I have no idea how to prevent from using unwrap or match many times in rust.
Sean Perry
@shaleh
May 11 2016 23:48
the eval of a Maybe in Haskell will panic too
which is what unwrap() does. It assumes the value is a good one.
In Haskell there is the Monad idea which allows chaining. a >> b >> c will short circuit if a Maybe, Either or whatever is in error
There does not appear to be this syntactic assistance in Rust
nishidy
@nishidy
May 11 2016 23:59
Ok, then inevitably we should check to assure the value by calling unwrap(). This is like the way to check the error every time in golang