# impl\<T, U: From\<T\>\> From\<Vec\<T\>\> for Vec\<U\>

**URL:** <https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116>\
**Category:** libs\
**Created:** [July 9, 2023, 12:16pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116 "2023-07-09T12:16:06Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ddystopia](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ddystopia/32/10915_2.png) [@Ddystopia](https://internals.rust-lang.org/u/Ddystopia)\
**Post date:** [July 9, 2023, 12:16pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/1 "2023-07-09T12:16:06Z")

</div>

Considering that code snippet

```rust
struct Newtype(usize);

impl From<usize> for Newtype {
    fn from(item: usize) -> Self {
        Newtype(item)
    }
}

fn main() {
    let us: usize = 0;
    let newtype: Newtype = us.into(); // works

    let vec: Vec<usize> = vec![0, 1, 2];
    let vec_newtype: Vec<Newtype> = vec.into(); // not works
}

```

Maybe it would be better to have an impl such like

```rust
impl<T, U> From<Vec<T>> for Vec<U>
where
    U: From<T>,
{
    fn from(item: Vec<T>) -> Self {
        item.into_iter().map(U::from).collect()
    }
}

```

In the standard library?

Could it be considered if I'll make a PR like this?

Also I have a question, wouldn't it be useful for all types? To automatically have `Into`, if all generics do have `impl Into`? Maybe if `Into` is unwanted, it could be possible to opt out them with negative impl?

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [July 9, 2023, 12:24pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/2 "2023-07-09T12:24:22Z")

</div>

This impl would overlap and thus conflict with the reflexive `impl<T> From<T> for T`.

---

<div class="post-metadata">

**Author:** ![Ddystopia](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ddystopia/32/10915_2.png) [@Ddystopia](https://internals.rust-lang.org/u/Ddystopia)\
**Post date:** [July 9, 2023, 12:28pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/3 "2023-07-09T12:28:15Z")

</div>

But it is allowed to use `min_specialization` in standard library, isn't it?

`item.into_iter().map(U::from).collect()` should be optimized out if `T == U`

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [July 9, 2023, 12:30pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/4 "2023-07-09T12:30:20Z")

</div>

As far as I know, at the moment, specialization is used in the standard library only for performance optimizations, _ **not** _ to write publicly visible trait implementations that are impossible without specialization.

Also specialization is of limited help here, since not one implementation is more general than the other, but we have two _overlapping_ ones, but both `impl`s contain cases the other one doesn’t.

---

<div class="post-metadata">

**Author:** ![Ddystopia](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ddystopia/32/10915_2.png) [@Ddystopia](https://internals.rust-lang.org/u/Ddystopia)\
**Post date:** [July 9, 2023, 12:37pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/5 "2023-07-09T12:37:19Z")

</div>

Yes, I see now. But could it be helped in some other way, because it would be really convenient to have such a feature:

```rust
    let vec: Vec<usize> = vec![0, 1, 2];
    let vec_newtype: Vec<Newtype> = vec.into(); 

```

?

Maybe with [More flexible coherence rules that permit overlap · Issue #1053 · rust-lang/rfcs · GitHub](https://github.com/rust-lang/rfcs/issues/1053) (mutually exclusive traits) and to specify that T != U (somehow) it would be possible?

And thank you very much for your answers.

---

<div class="post-metadata">

**Author:** ![SkiFire13](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/skifire13/32/7579_2.png) [@SkiFire13](https://internals.rust-lang.org/u/SkiFire13)\
**Post date:** [July 9, 2023, 1:00pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/6 "2023-07-09T13:00:12Z")

</div>

> [@Ddystopia](#):
>
> Maybe with [More flexible coherence rules that permit overlap · Issue #1053 · rust-lang/rfcs · GitHub](https://github.com/rust-lang/rfcs/issues/1053) (mutually exclusive traits) and to specify that T != U (somehow) it would be possible?

You can't specify `T != U` though.

Can't you just do `.into_iter().map(Into::into).collect::<Vec<_>>()`? Or maybe write a helper function for it with a short name, like `vec_into`.

---

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [July 11, 2023, 7:52pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/7 "2023-07-11T19:52:16Z")

</div>

> [@steffahn](#):
>
> As far as I know, at the moment, specialization is used in the standard library only for performance optimizations, _ **not** _ to write publicly visible trait implementations that are impossible without specialization.

Exactly this.

`From` impls like this are widely desired -- `Option` wants an analogous one, for example -- but can't happen yet.

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [October 9, 2023, 7:53pm UTC](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/8 "2023-10-09T19:53:04Z")

</div>

Closed on October 9, 2023, 7:53pm UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.