In expressions that create arrays it's [array repeat expression; how many elements are in the array]. The expression is used to initialize every element of the array.
The expression must be copyable, because one expression is going to be copied to all elements of the array.
However, String in Rust is uniquely owned. It can't be trivially copied. It can be only manually cloned, and the array literal syntax doesn't do cloning.
This is a usability problem with fixed-size arrays in Rust. They're generally hard to work with. A simple workaround may be to use Vec instead, which clones its initialization expression:
let vec = vec![String::from("hello"); 10];
For fixed-size arrays there is a silly workaround involving two quirks:
Empty String is a special case that can exist as a compile-time constant (other heap-allocated text can't, because there's no heap at compile time).
Compile-time constants can be used to initialize arrays.
const EMPTY_STRING: String = String::new();
let arr = [EMPTY_STRING; 10];
Thank you for your reply. I still dont understand this.
If I want to retain move semantics, how can I use this syntax?
struct Cloneable{
i :u32,
}
impl Clone for Cloneable{
fn clone(&self) -> Cloneable{
return Cloneable{
i: self.i,
}
}
}
impl Copy for Cloneable{}
let arr = [ Cloneable{i:1}; 10]; // Cloneable is forced to be Copyable
let s = Cloneable{i:0};
let r = s; //
let r2 = s; // move semantics is lost. So `s` is still valide.
Why not just require Cloneable (not Copyable), so that this syntax is more useable? Like
let a = [ "hello rust".to_string(); 10]; // String impl Clone. OK
struct S{
// contains data on heap. simple memcpy is not satisfied
}
impl Clone for S{
fn clone(&self)->S{
// data on heap is cloned properly
}
}
let a = [ S{..}; 10]; // S impl Clone. OK
let s = S{..};
let r = s;
let r2 = s; // compile error! S retains move semantics.
Some bookkeeping is required to know how many elements to drop if a panic happens while you're cloning elements. Vec keeps track of how many elements have been initialized but plain arrays do not. You can use the 'array-init' crate to efficiently initialize arrays without a Copy requirement and without leaking memory if initialization fails: https://crates.io/crates/array-init
You might argue that this functionality should be standard in Rust, but, for better or worse, it is not.
impl const Trait or something analogous will be needed for .clone() in a const context. A tool could perhaps be built around something else though, in the meanwhile. (Even then, Rust tends to prefer potentially expensive operations be more explicit; a macro or similar is more likely then implicit cloning IMO.)
It's easy to see how Copy is a specialized version of Clone, for one. Also, coherence says that there must be an unambiguous implementation of a trait for a given input type. So you can't have this, for example:
pub trait MyTrait {}
impl <T: Clone> MyTrait for T {}
impl <T: Copy> MyTrait for T {}
And just having Copy is often too limiting, as would be excluding types that are Copy. By making Clone a super trait, the restriction is lifted with an acceptable loss of generality (no Copy but non-Clone types).
impl Copy basically means "I don't want move semantics".
From Rust's perspective this is an unsolvable problem. You try to implicitly init 10 elements with 1 object, but at the same time you want to forbid implicitly copying of the object.
Fixed-size arrays are awfully inflexible like that. They will not do what you want. Don't use them.
Use Vec. Use ArrayVec instead. These types support initializing with non-Copy types.
Thanks for your advice.
I give up with Fixed-size arrays and use Vec instead.
Hope there will be a better version of Array, as Array is such a basic thing in programming.
Usually, for languages where the equivalent is not Vec<T>, such as Java where there is a fixed length int[] type, the actual equivalent is an Box<[T]>. You can create one of those by cloning an element with vec![elem; len].into_boxed_slice().
