make creating arrays of types that are not `Copy` less painful

[vks]

It would be very nice if

let array = [$expression; N];

was syntactic sugar for

let array = [$expression, $expression, $expression, ...];

This would allow things like

let bools = [AtomicBool::new(false); 10];
let array: [T; 10] = [Default::default(); 10];

Currently it only works for values that implement Copy. For the use case above, there is currently not really any alternative to just writing [$expr, $expr, ...].

I think this is a backwards-compatible change.

[vks]

This is actually problematic regarding idempotency: Currently [rand(); 10] is not the same as [rand(), rand(), ...]. However, I still think we need an alternative to [AtomicBool::new(true), ...]. (Note that it cannot be implemented as a panic-safe macro AFAIK.)

[bluss]

I think you mean not Copy actually. Another good example is filling an array with None, where basically that particular enum variant "is Copy".

[eddyb]

The way I would do it is by supporting both Copy variables and any constants.
We have the qualification logic for constants, so this wouldn't be much of a hassle to implement.

In the case of constants, the "syntactic" expansion that you propose would be correct, as one could always write the same expression multiple times and it would result in the same value.
Though you still wouldn't be able to write [AtomicBool::new(false); N] without const fn.

[vks]

Maybe we should have a new construct that is equivalent to [expr, expr, ...]. This macro [1] comes close, but is not panic-safe:

macro_rules! init_array(
    ($ty:ty, $len:expr, $val:expr) => (
        {
            let mut array: [$ty; $len] = unsafe { std::mem::uninitialized() };
            for i in array.iter_mut() {
                unsafe { ::std::ptr::write(i, $val); }
            }
            array
        }
    )
);

fn main() {
    let myarray = init_array!(AtomicBool, 10, AtomicBool::new(false));
}

[1] https://www.reddit.com/r/rust/comments/33xhhu/how_to_create_an_array_of_structs_that_havent/cqqf9tr

[eddyb]

I would suggest not adding anything language-level because that usecase can be fulfilled with iterators and collecting to [T; N] when we get value parametrization in generics.

[vks]

We still need to solve the panic-safeness problem, don't we?

[Kimundi]

With integer values in generics and #197 it would be possible to define a FixedSizeVec<T, N> which would be just as panic safe as a Vec<T>, and which can have a unwrap method for turning it into a [T; N]

[benw]

Re @eddyb's suggestion of supporting Copy variables or constants, that might still leave room for disappointment:

struct Foo;
let x = rand();
let array: [Result<u32, Foo>; 10] = [Ok(x); 10];

Ok(x) is not a constant, but it's still suitable to be copied into all the array elements.

[eddyb]

@benw I guess the reformulation required there would be "ADT tree of Copy leaves" with e.g. None having no Copy leaf and Ok(x) having x: u32 as its only leaf, and u32 is Copy, so they would both work.

The only other kind of non-Copy values which can come from constants are &mut T, so this formulation alone, without the "or constants" I had, wouldn't allow for, e.g. [&mut []; 100].

But at least that's a backwards-compatible change to make later - and this "ADT tree of Copy leaves" can be checked in a simpler fashion than "or constant" (which requires moving the check to a later pass): traverse the HIR, recursing into struct/variant ctors (both Foo(...) and Bar {...} forms) and checking all other expressions' types for Copy.