# Why is \`ToOwned\` in \`alloc\`?

**URL:** <https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999>\
**Category:** language design\
**Created:** [February 11, 2026, 10:41pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999 "2026-02-11T22:41:56Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\
**Post date:** [February 11, 2026, 10:41pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/1 "2026-02-11T22:41:56Z")

</div>

I have a case where I'd like to accept either a reference to a stack-allocated type, which could use `ToOwned` by way of the blanket impl of that trait for `T: Clone`, or when the `alloc` feature is enabled, I have a slice-like type whose `ToOwned` impl turns it into a heap-allocated type.

Unfortunately, for `ToOwned` to even be available, `liballoc` must be linked, and AFAICT it has no actual dependencies on anything heap-related, it's just by convention it's only used with heap-allocated types.

Is there a specific reason it's in `liballoc` instead of `libcore` alongside `core::borrow::Borrow(Mut)`?

---

<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:** [February 11, 2026, 10:49pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/2 "2026-02-11T22:49:42Z")

</div>

> <https://github.com/rust-lang/libs-team/issues/519>
>
> \# Proposal
> 
> \## Problem statement
> 
> The standard library's \`alloc\` crate defines t…he \`ToOwned\` trait and the \`Cow\` type in the \`borrow\` module. This module is closely tied to Rust's ownership model, and the \`core\` crate also defines some facilities in this module (i.e. the \`Borrow\` and \`BorrowMut\` traits).
> 
> Whilst both \`ToOwned\` and \`Cow\` are usually used in conjunction with the \`alloc\` crate's dynamically-allocated types (such as \`String\` and \`Vec\`), they do not intrinsically \*need\* to be coupled with these types.
> 
> The issue with having these items in \`alloc\` is that it renders it impossible for crates to implement \`ToOwned\` for their own types (without, of course, importing either \`alloc\` or \`std\`). This is despite the fact that it is theoretically possible to define this trait without using any other facilities from \`alloc\` or \`std\` (the ownership model, at least, exists no matter the combination of crates used).
> 
> \## Motivating examples or use cases
> 
> Third-party crates that define their own sense of borrowed vs. owned types would naturally want to implement \`ToOwned\` for the borrowed types. But this currently requires importing either of the \`alloc\` or \`std\` crates, which may not necessarily be wanted (especially if the crate uses the \`no\_std\` attribute).
> 
> \## Solution sketch
> 
> Move the definitions of \`ToOwned\` and \`Cow\` into \`core\`:
> 
> \`\`\`rust
> // core::borrow;
> 
> pub trait ToOwned {
> type Owned: Borrow\<Self\>;
> 
> fn to\_owned(&self) -\> Self::Owned;
> 
> fn clone\_into(&self, target: &mut Self::Owned);
> }
> 
> pub enum Cow\<'a, B\>
> where
> B: ToOwned + ?Sized + 'a
> {
> Borrowed(&'a B),
> 
> Owned(B::Owned),
> }
> 
> impl\<'a, B\> Cow\<'a, B\> {
> pub fn to\_mut(&mut self) -\> &mut B::Owned;
> 
> pub fn into\_owned(self) -\> B::Owned;
> }
> 
> // Remaining implementations for \`Cow\`...
> \`\`\`
> 
> As the \`Cow\` type is very closely related to \`ToOwned\`, I do not see any reason for keeping it separated should \`ToOwned\` be moved to \`core\`.
> 
> \## Alternatives
> 
> Third-party crates could define their own \`ToOwned\` or \`Cow\`. But this would be completely redundant as the standard items already exist, albeit in an incompatible context.

Looks like the main issues are

```rust
impl ToOwned for str {
    type Owned = String;
    // …
}

```

and

```rust
impl<T: Clone> ToOwned for [T] {
    type Owned = Vec<T>;
    // …
}

```

since `str` and `[T]` are in `core`, so if `ToOwned` also is in `core` but `String` and `Vec<T>` aren’t, we have orphan impl problems.

---

<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:** [February 11, 2026, 10:59pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/3 "2026-02-11T22:59:58Z")

</div>

Maybe it'll add into motivation for changing that annoying rule 🫣

---

<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:** [February 11, 2026, 11:19pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/4 "2026-02-11T23:19:29Z")

</div>

Its not that easy - just turning it off would be unsound. For example [with trait objects, you can write code](https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=80a7d7908a3e54c4fb4887bddd09e863) that strictly relies on no new (i.e. additional) downstream impls appearing for an already known\[1\] trait on already known types.

* * *

1. i.e. local or upstream

---

<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:** [February 11, 2026, 11:22pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/5 "2026-02-11T23:22:26Z")

</div>

The rule exists for good reason, so probably isn't going away. After all, `alloc` is "just" a crate, so if it can `impl core::ToOwned for core::str {`, then so could everyone on [crates.io](http://crates.io) and they could all stomp on each other.

* * *

Note that there's an important polarity difference to the rule, though.

If we had `core::FromOwned`, then it'd be perfectly fine to have `impl<T> core::FromBorrowed for alloc::Vec<T> { type Borrowed = [T]; }` in `alloc`, and _also_ to have other things like `impl<T> FromBorrowed for some_crate::SmallVec<T> { ... }` too. (Maybe even `FromBorrowed<[T]>` -- I haven't thought through all the implications yet.)

So what I really wish for is a better way to move from one trait to another without breaking everything and without blanket overlap rules preventing it from working.

---

<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:** [February 12, 2026, 7:41am UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/6 "2026-02-12T07:41:32Z")

</div>

Yes, that's why I tell "change".

---

<div class="post-metadata">

**Author:** ![SciMind2460](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scimind2460/32/13125_2.png) [@SciMind2460](https://internals.rust-lang.org/u/SciMind2460)\
**Post date:** [February 12, 2026, 12:48pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/7 "2026-02-12T12:48:35Z")

</div>

~~I'm sorry if I don't understand, but couldn't we do something like `#[rustc_allow_incoherent_impl]`?~~

Edit: Ahh... it appears it's only on inherent impls. I wonder why we could not allow it on traits though?

---

<div class="post-metadata">

**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\
**Post date:** [February 12, 2026, 10:00pm UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/8 "2026-02-12T22:00:39Z")

</div>

Thanks for linking that issue! I should've searched harder 😅

Regarding orphan rules, there is a recent comment in the linked issue that shows it's possible to move `ToOwned` to `core` with appropriate incoherence overrides: [wip: Move `ToBorrow` to `core` · cvengler/rust@943fc34 · GitHub](https://github.com/cvengler/rust/commit/943fc345832bbf2e0b1e7390ca1900c0b9922c61)

---

<div class="post-metadata">

**Author:** ![HjVT](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/hjvt/32/10365_2.png) [@HjVT](https://internals.rust-lang.org/u/HjVT)\
**Post date:** [February 13, 2026, 1:48am UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/9 "2026-02-13T01:48:00Z")

</div>

This problem also exists for users with multi-crate workspaces. They can have assurances that technically orphan impls are coherent, but there's no way to explain that to rustc.

(There are more pressing issues with workspaces, though, like how dead code lints break down across module-like crate boundaries)

---

<div class="post-metadata">

**Author:** ![theemathas](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/theemathas/32/11817_2.png) [@theemathas](https://internals.rust-lang.org/u/theemathas)\
**Post date:** [February 13, 2026, 6:02am UTC](https://internals.rust-lang.org/t/why-is-toowned-in-alloc/23999/10 "2026-02-13T06:02:55Z")

</div>

Here's a closed PR that attempted to add a flag to override orphan rules, to allow for ToOwned in core: [Allow incoherent trait implementations by cvengler · Pull Request #150652 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/pull/150652)

It was closed because depending on a dependency crate that has `extern crate alloc;` would cause even more weird behavior that there already is. See [Name resolution of `rustc_allow_incoherent_impl` methods affected by mention of dependency · Issue #149347 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/149347)