Hello,
I am searching for the easy or standard way to return an item from a collection.
Here is a fictional example showing the issue:
struct Coll<Item> {
items : ~[Item]
}
impl<Item> Coll<Item> {
fn first (&self) -> Item {
// this line is for comments below:
let it = self.items[0]; // error
return it;
}
}
fn main () {
let coll = Coll{items:~[1,2,3]};
println!("first : {:?}", coll.first());
}
==>
_.rs:12:18: 12:30 error: cannot move out of dereference of & pointer
_.rs:12 let it = self.items[0];
I could not find any clue in docs. Have tried several approaches, finally
succeeded with the following:
impl<Item:Clone> Coll<Item> {
fn first (&self) -> Item {
let it = self.items[0].clone();
return it;
}
}
I find that surprising. A few questions:
* What does the error *mean* ?
* Is this solution the right way?
* What alternatives exist, if any?
* What is the difference between copy and clone?
* Why does clone work and not simple copy?
About the latter 2 questions, well, for me,
y = x
just copies x into y [1]; and clone is just a synonym of copy. Where am I wrong?
That we copy should remove any pointer safety question, shouldn't it? (This
consideration was my lead to find a solution.) Again, where am I wrong?
The doc of the module 'clone' reads:
<< The Clone trait for types that cannot be "implicitly copied"
In Rust, some simple types are "implicitly copyable" and when you assign them or
pass them as arguments, the receiver will get a copy, leaving the original value
in place. These types do not require allocation to copy and do not have
finalizers (i.e. they do not contain owned boxes or implement Drop), so the
compiler considers them cheap and safe to copy. For other types copies must be
made explicitly, by convention implementing the Clone trait and calling the
clone method. >>
This is all good and makes sense for me. But then, in the first code example
above, the compiler does not know anything about the "copy-ability" of Val
specimens. 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? Then, the
language should require Val to declare the trait Clone, shouldn't it? And there
should not be a need for an explicit copy via the clone method in my view...
Again, what other sense but copying does the compiler assign to a simple
assignment "y=x" ?
Finally, is it so that for generic collections, item types must always be
declared the Clone trait, else we just cannot read them? Same for generic struct
fields? (If I add a field of type Item in Coll, I also cannot read it out
without error.)
Denis
[1] shallow copy: the pointer, if x is a pointer, the "façade" struct is x is
such an thing, etc...
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
