should be possible to do [CopyableVariant, ..n] for a non-copyable type

[thestinger]

This should be fixable by special casing this (the type isn't copyable, but for this specific case the variant is).

This problem only exists with fixed-size vectors since vec::from_fn(10, |_| None) works with non-copyable types.

@nikomatsakis thinks this should be fixable

[bstrie]

Does this suffice as a test case?

struct Foo;

impl Drop for Foo { fn finalize(&self) {} }

fn main() {
    let y = Foo;
    let x = [y, ..10];
}

I'm not sure what you mean by that from_fn comment, as changing the last line to let x = std::vec::from_fn(10, |_| y); also fails.

[nikomatsakis]

vec::from_fn(10, |_| Foo) should pass, though. I think a good test case is:

fn main() {
    let x = [None::<~str>, ..10];
}

which I believe will fail to compile.

[thestinger]

This is still an annoying issue. :)

[lilyball]

It seems to me that the more general solution is coming up with some way to say [expr, ..N] that acts as if you had repeated expr that many times, instead of trying to Copy it. I could imagine implementing this as a procedural macro (but not as macro_rules!).

[nikomatsakis]

At some point, we discussed applying a similar test to the one that we
use for static initializer values -- basically distinguishing values
that need drop from types that need drop, and preventing .. from
being applied to the latter. Specifically this would allow you to
write [None, ..10]. This is my preferred solution right now.

[lilyball]

I submitted PR #14272 which adds ary![expr, ..N] that expands to [expr, expr, expr, expr, ..., expr] (N times). This is partially a workaround for the lack of [CopyableVariant, ..N], but also allows for using expressions that will never be copyable, such as ary![Vec::new(), ..64].

[Gankra]

cc me

[steveklabnik]

closing in favor of rust-lang/rfcs#832, which is going to end up doing this.

[Gankra]

That RFC only provides the functionality in the vec macro through Clone. This still wouldn't allow a vec![None::<SomethingNotClone>; 10], and of course has no affect on the standard [T; n] syntax.

[steveklabnik]

Ah, I mis-read: I thought that it was supporting non-Clone too.

[steveklabnik]

Moving to the RFC repo generally rust-lang/rfcs#1366