# Blanket implementation for \`impl\\> Into\\> for Option\\` **URL:** \ **Category:** libs\ **Created:** [August 29, 2023, 9:41am UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442 "2023-08-29T09:41:07Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![heksesang](https://avatars.discourse-cdn.com/v4/letter/h/e47c2d/32.png) [@heksesang](https://internals.rust-lang.org/u/heksesang)\ **Post date:** [August 29, 2023, 9:41am UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442/1 "2023-08-29T09:41:07Z")
Why doesn't the standard library have a blanket implementation for `impl> Into> for Option`? It's rather inconvenient that there is no `Into> for Option` when there is an `Into for A`, as this tends to make `Option`s less convenient in some scenarios (e.g. macros that expect there to exist an `Into`, but you have to use `Option` instead of `B` and therefore there is no `Into` even though it _could_ have existed). ---
**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:** [August 29, 2023, 9:43am UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442/2 "2023-08-29T09:43:25Z")
This implementation would overlap with the generic `impl From for T` implementation, and thus be rejected by the compiler. Feel free to try it yourself 🙂 `Option` is re-defined easily enough as `enum Option { None, Some(T) }` ---
**Author:** ![dlight](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dlight/32/8462_2.png) [@dlight](https://internals.rust-lang.org/u/dlight)\ **Post date:** [August 29, 2023, 10:10am UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442/3 "2023-08-29T10:10:36Z")
Could specialization work around that? ---
**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:** [August 29, 2023, 10:12am UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442/4 "2023-08-29T10:12:10Z")
Specialization is currently not used in order to write public, otherwise impossible trait implementations. The standard library only uses it for performance optimizations that could – at least in principle – all still be removed if necessary.' See also this relatively recent similar topic: [impl\\> From\\> for Vec\ - #7 by scottmcm](https://internals.rust-lang.org/t/impl-t-u-from-t-from-vec-t-for-vec-u/19116/7) ---
**Author:** ![heksesang](https://avatars.discourse-cdn.com/v4/letter/h/e47c2d/32.png) [@heksesang](https://internals.rust-lang.org/u/heksesang)\ **Post date:** [August 29, 2023, 10:42am UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442/5 "2023-08-29T10:42:56Z")
Maybe specialisations should be used for this then? Is there any good reason specialisation shouldn't be used for this? ---
**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:** [August 29, 2023, 12:04pm UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442/6 "2023-08-29T12:04:35Z")
My interpretation of the situation would be: specialization is a severely incomplete language feature with a lot of hard unsolved design issues. Nobody knows what specialization will look like when (if?) it ever gets stabilized in any form; and consequently nobody knows what use-cases exactly will be supported by any future actual specialization feature. It thus would be too strong a commitment to use the flawed status-quo of specialization in order to implement trait implementations in ways that – however desirable they may be in principle \[1\] – might never be supported. Once such a trait implementation would be offered, Rust’s stability means it’s a commitment to support it indefinitely. Incidentally, even the current flawed specialization feature can not (or was it possible, but complicated?) support overlapping implementations where one is not strictly more concrete than the other. The generic `impl From for T` and a `impl, U> From> for Option` overlap for the case `T == Option == Option, U == V`, but both cover cases the other one doesn’t cover. That being said, this is only my personal take. Probably somewhere (though I don’t know where exactly) there’s existing discussions presenting the “official” reason for why we don’t expose specialization in public trait implementations of the standard library. * * * 1. though in this case, as `From` and `Into` are merely convenience traits anyways, there isn’t even a particularly strong argument to begin with why we would absolutely _need_ the trait implementation in question ---
**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:** [November 27, 2023, 12:05pm UTC](https://internals.rust-lang.org/t/blanket-implementation-for-impl-t-u-into-t-into-option-t-for-option-u/19442/7 "2023-11-27T12:05:05Z")
Closed on November 27, 2023, 12:05pm UTC This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.