Suggest array::from_fn in array initialization

[est31]

For this snippet (playground):

fn foo() -> String { String::new() }

fn main() {
    let string_arr = [foo(); 64];
}

rustc gives:

error[E0277]: the trait bound `String: Copy` is not satisfied
 --> src/main.rs:3:23
  |
3 |     let string_arr = [foo(); 64];
  |                       ^^^^^ the trait `Copy` is not implemented for `String`
  |
  = note: the `Copy` trait is required because this value will be copied for each element of the array

Since #113912, for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because foo is not const fn. However, we can suggest array::from_fn instead.

[est31]

Personally, I prefer array::from_fn over a separate const binding. Even in the const case, the generated code will call the initialization function many times. Maybe in the case where const bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest array::from_fn there.

@Nilstrieb @lcnr what do you think?

[Noratrieb]

Once inline_const is stable we can suggest that :3. But until then array::from_fn sounds reasonable.

[est31]

Agreed, good point about inline_const. It seems to have a stabilization PR open with an FCP, which is blocked: #104087 (comment) . Maybe there might be progress on it this month: #104087 (comment) .

Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.

[joboet]

I think this should (in the future) suggest array::repeat instead, since the function would only be called once if String were Copy, whereas from_fn calls it for every element.