These are chat archives for rust-lang/rust

29th
Apr 2017
VJ
@00imvj00
Apr 29 2017 08:26
match current_node {
                     ref mut Link::Empty => {
                      println!("This is empty");
                      break;
                     },
                     ref mut Link::More(node) => {
                        println!("more.");
                        break;
                     }
               }
what is wrong with this ?
ignore break statement.
it is throwing, expected one of =>, @, if, or |, found ::
Ingvar Stepanyan
@RReverser
Apr 29 2017 08:28
you can't use ref::mut in this place because it basically says "dereference" (just like *), and you can't dereference enum values
just strip it
VJ
@00imvj00
Apr 29 2017 08:28
how do i do that ?
Ingvar Stepanyan
@RReverser
Apr 29 2017 08:28
well just remove it from code ;)
VJ
@00imvj00
Apr 29 2017 08:28
because i am passing reference to that enum
ha ha
cool
expected &mut Link, found enum Link
Ingvar Stepanyan
@RReverser
Apr 29 2017 08:29
if it's a reference, then you need to either use &Link::Empty etc. in matches or just match *current_node
VJ
@00imvj00
Apr 29 2017 08:29
error
Ingvar Stepanyan
@RReverser
Apr 29 2017 08:29
second is usually preferable, less noise
and then for node itself (inside second match) you add ref mut
match *current_node {
                     Link::Empty => {
                      println!("This is empty");
                     },
                     Link::More(ref mut node) => {
                        println!("more.");
                     }
               }
like this
VJ
@00imvj00
Apr 29 2017 08:31
let mut current_node: &mut Link = &mut self.head;

            while let &mut Link::More(ref mut node) = current_node {
              if let Link::Empty = node.next {
                 let new_node = Box::new(Node{
                                  value: arg,
                                  next:  mem::replace(&mut node.next, Link::Empty),
                                });
                     node.next = Link::More(new_node);
              }
              println!("{:?}", node);
              current_node = &mut node.next;  
            }
so what i am trying out here, is i am trying to append the node in linked list.
Ingvar Stepanyan
@RReverser
Apr 29 2017 08:31
if let Link::Empty = node.next {
VJ
@00imvj00
Apr 29 2017 08:32
cannot borrow `current_node.0` as mutable more than once at a time
  --> src/main.rs:38:39
   |
38 |             while let &mut Link::More(ref mut node) = current_node {
   |                                       ^^^^^^^^^^^^
   |                                       |
   |                                       second mutable borrow occurs here
   |                                       first mutable borrow occurs here
...
62 |    }
   |    - first borrow ends here

error[E0506]: cannot assign to `current_node` because it is borrowed
  --> src/main.rs:47:15
   |
38 |             while let &mut Link::More(ref mut node) = current_node {
   |                                       ------------ borrow of `current_node` occurs here
...
47 |               current_node = &mut node.next;  
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ assignment to borrowed `current_node` occurs here

error: aborting due to 2 previous errors

error: Could not compile `linked_list`.
Ingvar Stepanyan
@RReverser
Apr 29 2017 08:32
for simple statement like that you can just use node.next == Link.Empty btw
although that's irrelevant
VJ
@00imvj00
Apr 29 2017 08:33
i want to know the reason, why this error.
but if i use if then i will have to use loop right ?
@RReverser
Ingvar Stepanyan
@RReverser
Apr 29 2017 08:35
linked lists and borrow checker are hard (especially when you traverse mutably) :(
VJ
@00imvj00
Apr 29 2017 08:35
ha ha ..
ok.
VJ
@00imvj00
Apr 29 2017 08:46
what is the difference between Box<> and Rc<> ??
i read the doc, it says Box<> is owned pointer, so there will be one owner at a time, while with Rc<> there can be multiple owners.
so it means can we use Rc<> instead of Box<> to make process of Borrow checker bit easy, where we suppose to use Box<> ?
Ingvar Stepanyan
@RReverser
Apr 29 2017 10:02
Yeah, but use only when really needed, as Rc adds runtime overhead
While with Box Rust already knows that there is only one owner and it can compile-check all usages and just use raw pointer when compiled, with Rc it has to generate actual usage counter in addition to pointer itself, and insert runtime ifs on every use to figure out when usage goes to zero and it actually needs to free it
Frank McSherry
@frankmcsherry
Apr 29 2017 10:15
I think it only needs to check and mutate counts on clone and drop. When you deref through the Rc it knows that the value is live and doesn't need any conditional logic.
Ingvar Stepanyan
@RReverser
Apr 29 2017 10:15
yes, but that's still expensive
I mean, if you want to use Rc at all, you likely use such clones/drops quite often
VJ
@00imvj00
Apr 29 2017 10:16
thn how should i do it.
?
Frank McSherry
@frankmcsherry
Apr 29 2017 10:16
Well, "as compared to Box", which I think was the question, tweaking the count is less expensive than allocating / de-allocating.
Ingvar Stepanyan
@RReverser
Apr 29 2017 10:17
Yeah but Box is only one, you usually just reborrow it around
only when that's totally impossible due to complex logic that can't be expressed with lifetimes, then Rc / RefCell / etc. should be used
VJ
@00imvj00
Apr 29 2017 10:30
can we solve it with recursion ?
in recursion, there will be only one borrow at a time right ?
what you think ?
Ingvar Stepanyan
@RReverser
Apr 29 2017 10:34
looking at your code above - you're just trying to add item to the end of list, right?
VJ
@00imvj00
Apr 29 2017 10:34
yes.
but for that , i need to check.
so instead of mut current_node, can u get just reference of current node ?
Ingvar Stepanyan
@RReverser
Apr 29 2017 10:35
so why don't you just break when .next is Link::Empty, thus avoiding two borrows at once
and then adding outside of the loop
VJ
@00imvj00
Apr 29 2017 10:35
was doing same only.
the thing is, i am borrowing Link and mut and also node inside that link as mut, that is where it is giving me error i guess.
we can not do that right ?
Cengiz Can
@cengizIO
Apr 29 2017 13:57
Hola! anyone attending to RustFest Kiev tomorrow?
Aleksey Kladov
@matklad
Apr 29 2017 19:06
@cengizIO I am already in Kiev :)
Martell Malone
@martell
Apr 29 2017 19:46

Hey all just spending my Saturday learning rust :) I was wondering if anyone could give me your perspective on the following.

This a technically a general rust question but my example involves futures and hyper

I am using tokio and hyper
I want a Bool to decide if we should handle a Http requests or not.
When using hyper and tokio I would have to Arc<Mutex<Bool>> clone the arc and pass it to the for_each http handler and then do an if to decide to handle the connection or not because each request is done on a different thread. If say one thread is only ever going to write to the Bool to change it to true or false but each for_each only need to read it.
Is there a way to do this without a mutex lock? (Going a little against the point of rust here I know)

Denis Lisov
@tanriol
Apr 29 2017 20:03
@martell You can use an AtomicBool which does not need a lock.
Martell Malone
@martell
Apr 29 2017 20:22
Ohh nice, thanks @tanriol.
Is there any cost involved with using Atomic Types?
Ilya Bogdanov
@vitvakatu
Apr 29 2017 20:24
@martell, yes, it is.
Martell Malone
@martell
Apr 29 2017 20:24
it is?
Denis Lisov
@tanriol
Apr 29 2017 20:24
There is some cost, but probably much lower than a mutex.
Martell Malone
@martell
Apr 29 2017 20:24
ahh I see
get_mut seems to be the same as locking which is cool
valamorgon
@valamorgon
Apr 29 2017 20:26
Hi, I am a web developer who is interested in recommendation engines and other web 3.0 stuff. Should I start learning rust for investing in future? Why do you use rust? What is it good for? Wo do you recommend it?