On 11/11/2013 02:47 PM, Felix Klock wrote:
Denis (cc'ing rust-dev)-
Thank you very much, Felix, for this clear and exhaustive reply.
How does it then interpret the line:
let it = self.items[0];
The only way to make sense of that is to copy, isn't it? What else?
An assignment expression can denote either a copy or a *move* of the
right-hand-side into the left-hand-side.
Note that your goal ("returning an item from a collection") is unclear, in that
I cannot tell whether you want to move item out of the collection, or make a copy of it,
or provide a shared reference to the item in the collection (but without removing it from
the collection).
All right. Seems 'move' is to be understood quite literally, no? The datum
so-to-say ceases to exist at its original place?
I want to copy because (or so it seels to me) it is the standard need: we want
something "equivalent". (By copy I do not mean deep copy or copy of contents or
of target, for a data structure, collection, or pointer. Just the "façade".)
Anyway, the error message says "cannot move out of dereference of & pointer"
In this case, the assignment expression is being interpreted as an attempt to
move content out of self.items[0]. But you cannot move the item out of the
l-value denoted
by that expression, for a couple different reasons (such as: `&self` is an
immutable borrow, so you cannot modify it; and also, even if you changed the
borrow to be a mutable borrow, you still could not use the expression you want to
extract the first item, since the vector needs something to replace the content
that was removed).
More or less what I understood, but thank to you clearer.
Maybe you are more used to languages like Java/Scheme/ML/Haskell/etc, where a
parameter or local variable denotes a *reference* to the value in question, and
thus can be freely copied? To get that effect in Rust, and thus allow multiple
references to some shared piece of state, you need to use some explicit
pointer/reference type.
Here is some code to illustrate what I'm saying. Note that you should probably
favor a data-structure representation where you can call the vec `pop()` method
rather than `shift()`; compare the source code for each in vec.rs to see why.
```rust
struct Coll<Item> {
items : ~[Item]
}
impl<Item> Coll<Item> {
// *Moves* the first element out of self.
// (Doing so requires that we mutably-borrow self.)
fn first (&mut self) -> Item {
// ^^^ this is new
let it = self.items.shift();
// ^^^^^ so is this
return it;
}
// Provides reference to first element of self.
fn first_ref<'a> (&'a self) -> &'a Item {
// Note: The lifetime 'a tells us that the reference will
// survive only as long as the immutable-borrow of self.
let it = &'a self.items[0];
return it;
}
}
fn main () {
let mut coll = Coll{items:~[1,2,3]};
// ^^^ this is also new.
{
// This {} block acts effectively as the lifetime 'a for the
// call to first_ref.
// First lets take a reference, `fref`, into coll...
let fref = coll.first_ref();
println!("first ref : {:?}", fref);
println!("coll : {:?}", coll);
// ... which will only live until here...
}
// ... which is important, because we need to *mutably*
// borrow `coll` in order to invoke `first()` here.
println!("first : {:?}", coll.first());
println!("coll : {:?}", coll);
}
```
All right! I'll keep this code aside for whenever I need these alternatives (ref
or move). I conclude that for reading or returning an item by copy, using clone
is the right way to go (if the item type is a variable). Correct?
Also, what does
let y = x;
mean in Rust if x's type is constant (as opposed to a generic type var)? Does it
depend on the exact type? and specifically what happens in the case of simple,
atomic, type?
Cheers,
-Felix
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
