Hacker News Reader

Comment by kzrdude | Hacker News Reader

I don't agree, because we can try the two following programs, and one of them does not compile. It compiles with underscore.

    let x = String::new();
    let _ = x;
    println!("{}", x);

    let x = String::new();
    x;
    println!("{}", x);   // ERROR: Use of moved value x.

And this is why I said that let _ = x; is a no-op. :)

View on HN

Huh, TIL! Had no idea `x;` actually moved `x`.

But where is it moved to? Who owns it now? Or is it just lost?

yes, it is dropped

Ahh, I remember a while back reading a blog where the author talked about `std::mem::drop` being their favorite standard library function because they used this effect. It is literately defined as:

    pub fn drop<T>(_x: T) { }

https://doc.rust-lang.org/std/mem/fn.drop.html

Right, so drop is useless :) We can drop things fine without it. Since of course it's scope/ownership based and not something that's explicitly called.

Well,

  drop(x);

is a lot clearer than

x;

So is drop like free, or is it something else?

Yes, it's effectively like free -- though C++'s "auto" is probably a closer idea.

The main difference to C's free is that you simply cannot double-free a value (without using unsafe). That's because a value is only dropped when it falls out of scope -- and since it values only have one owner (and references must not outlive values) there cannot be any dangling references after it's dropped.

The documentation for std::mem::drop is explaining that dropping a value is a property of the language and scoping rules -- thus there is nothing for the function to do other than take a value and let it go out of scope.

It’s more like delete in c++ because you can implement the Drop trait for a type in order to run code when it is dropped in order to clean up resources etc.

Drop is just what runs when a value goes out of scope. Like destructors in C++.

When you put it like that, I see that it's a rather minor detail.

I think no-op is a bit misleading, and throwing away is more precise, since Rust has strict evaluation.

    let _ = timeConsumingFunction();

Still needs to spend time performing timeConsumingFunction(). It might not move, but it still did the work and produced a result, you are just not using it (and hence not need to move it).

If you you had lazy evaluation I would agree with your argument for the no-op terminology.

That statement is different, the rhs is not a variable's name, so I agree with you, all of that is not a no-op.

Reply on news.ycombinator.com