Added standalone clone() and deep_clone() functions.

[Kimundi]

Right now, if you have an Iterator<&T>, like you get with vec.iter(), then for getting an Iterator<T> you have to do either of these:

// Only works for implicit copyable T, and can be confusing due to many pointers/sigils:
[1, 2, 3, 4].iter().map(|x| *x)...  
[1, 2, 3, 4].iter().map(|&x| x)...  

// Works for anything cloneable, but is long and can confuse the matters more due to autoderef:
[1, 2, 3, 4].iter().map(|x| x.clone())... 

These issues come regularly up while explaining Iterators to people on IRC, or for writing short understandable examples.

Having a standalone function of clone eases the situation: It's signature is &T -> T, and map transforms A -> B. Therefore map(clone) is easily explainable as removing an layer of & by making an copy through it:

[1, 2, 3, 4].iter().map(clone)... 

Just like std::from_str::from_str, these two functions are basically just workarounds for not being able to import associated functions from traits.

[dobkeratops]

+1 this makes perfect sense to me, I've independently discovered the need and I'm sure many others will, i think it will be very common.

although |x|x may not be many characters, its' more mental stages -faced with more complex single line expressions i would usually end up writing one-off helpers to make function bodies read more cleanly, even if it resulted in duplicate code. (what i'm saying is, if you *dont have the proposed clone function, many people will write it.. or soemthng else like .clone_collect() or .iter_clone() or whatever)

Perhaps anything that you can do in an operator would benefit from a helper-function that can easily be dropped into HOFs.. does that generalize ? (I'm reminded of how things work in haskell where operators are functions already)

i have a big draw to this 'functional' style of working from experience with low level optimization on game-consoles in the past (various forms of parallelism, requiring extensive manual tweaking of when/where/how details of an expression are executed, to work around severe cache & pipeline hazards), so its very important to me - its a big reason i'm interested in Rust in the first place.

One real world example is breaking up a complex loop body into 2 or more passes to avoid overflowing the I-cache. There are many cases where i need to manually reason about where something actually ends up... in my cases one is usually thinking about getting data into a specific layout
another is re-arranging data for use in SIMD instructions.. you might take some subset of a collection and filter/permute it ..

[alexcrichton]

This should probably get discussed more broadly before getting merged (prelude changes are always tricky).

I don't think this is the same as the from_str function because that was dealing with calling a static method on a trait. This is different in that it's a method on an object (not that it means a whole lot).

[brson]

Let's put it on the next meeting agenda.

[brson]

As discussed in today's meeting let's not do this right now. The need to create this standalone functions is seen as a code smell that other features are missing, such as uniform method calls or cloning iterators. I worry about the slippery slope of adding more and more functions like this to work around language deficiencies. Let's be conservative and hold off on this, revisit later.