Implement `From<{&,&mut} [T; N]>` for `Vec<T>` where `T: Clone`

[EFanZh]

Proposal

Problem statement

Currently, we have From<{&,&mut} [T]> for Vec<T> where T: Clone, I think we can also implement From<{&,&mut} [T; N]> for Vec<T> where T: Clone.

Motivation, use-cases

Suppose I want to convert an &[[u32; 4]] value to a Vec<Vec<u32>> type. Currently, I can write:

• items.iter().map(|item| item.to_vec()).collect::<Vec<_>>();
• items.iter().copied().map(Vec::from).collect::<Vec<_>>();

I want to be able to write:

• items.iter().map(Vec::from).collect::<Vec<_>>();

Solution sketches

Implement From<{&,&mut} [T; N]> for Vec<T> where T: Clone.

Links and related work

• From<&[T]>.
• From<&mut [T]>.
• Implementation PR: rust-lang/rust#111278.

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

[the8472]

The Type::method syntax is somewhat poorly supported. Many things don't work because auto-deref and coercions don't happen when you use that syntax. Adding trait impls to make up for the lack of auto derefs seems like a good solution for that deficiency.

Imo it's worth checking if this can be improved on the language side, e.g. by inserting an anonymous shim function. I don't know if that would be acceptable since it would result in a different Fn type in the iterator adapter.

[Amanieu]

We discussed this in the libs-api meeting today. We're happy to add this, but it might be worth doing a crater run to check for type inference failures.