Add Option::owned

[WaffleLapkin]

This PR adds the following public library APIs:

// alloc::option
impl<T: ?Sized> Option<&T> {
    pub fn owned(self) -> Option<T::Owned>
    where
        T: ToOwned;
}

impl<T: ?Sized> Option<&mut T> {
    pub fn owned(self) -> Option<T::Owned>
    where
        T: ToOwned;
}

// alloc::result
impl<T: ?Sized, E> Result<&T, E> {
    pub fn owned(self) -> Result<T::Owned, E>
    where
        T: ToOwned;
}

impl<T: ?Sized, E> Result<&mut T, E> {
    pub fn owned(self) -> Result<T::Owned, E>
    where
        T: ToOwned;
}

Option::owned is similar to Option::cloned and Option::copied, but uses the ToOwned trait.

---

I thought that would be easier, but since ToOwned is defined in the alloc crate this becomes incoherent :')

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[WaffleLapkin]

@rustbot label +T-libs-api -T-libs

[RReverser]

It should probably add same methods to Result as well, since it usually mirrors such Option utils (e.g. it also has copied & cloned).

[WaffleLapkin]

@RReverser Good catch! I'll add owned method to Result too.

[joshtriplett]

I like the concept of this, but as a nit on the name, I think this should be to_owned.

[RReverser]

I like the concept of this, but as a nit on the name, I think this should be to_owned.

That wouldn't be possible - .to_owned() can already be called on arbitrary T: Clone refs, including on &Option, and does something different:

let a: &Option<i32> = &Some(1);
let b: Option<i32> = a.to_owned();

[camsteffen]

What about borrowed?

let x = Some(String::new());
let y: Option<&str> = x.borrowed();

[WaffleLapkin]

@camsteffen your snippet can use .as_deref instead, are there any reasons/use cases to use Borrow instead of Deref?

[camsteffen]

Yeah I just realized that. Probably not many such use cases.

[zesterer]

Could an implementation for Option<Cow<T>> be added too?

Edit: On second thoughts, that might not be possible given that this would need to be an inherent method in core that mentions a type in std (unless std has magic privileges that allows it to circumvent that problem?)

[WaffleLapkin]

@zesterer we already need magic (#[rustc_allow_incoherent_impl]) to define T: ToOwned methods, since ToOwned is defined in alloc :)

Still, I don't think implementation for Option<Cow<T>> is possible -- Cow<T> can implement ToOwned which will overlap with the methods being added.

[bors]

☔ The latest upstream changes (presumably #102097) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[joshtriplett]

Suggested change

	/// to convert borrowed types to their owned variants. For example `Option<&[T]>` to
	/// `Option<Vec<T>>`
	/// to convert borrowed types to their owned variants. For example, `Option<&[T]>` to
	/// `Option<Vec<T>>`, or `Option<&str>` to `Option<String>`.

[joshtriplett]

@bors r+

[bors]

📌 Commit 2a6f61c has been approved by joshtriplett

It is now in the queue for this repository.

[matthiaskrgr]

@bors r- CI is not green

     Finished release [optimized] target(s) in 0.17s
std/option/index.html:274: broken link fragment `#impl-FromIterator%3COption%3CA%3E%3E` pointing to `std/option/enum.Option.html`
std/option/index.html:285: broken link fragment `#impl-Product%3COption%3CU%3E%3E` pointing to `std/option/enum.Option.html`
std/option/index.html:286: broken link fragment `#impl-Sum%3COption%3CU%3E%3E` pointing to `std/option/enum.Option.html`
std/result/index.html:321: broken link fragment `#impl-FromIterator%3CResult%3CA%2C%20E%3E%3E` pointing to `std/result/enum.Result.html`
std/result/index.html:332: broken link fragment `#impl-Product%3CResult%3CU%2C%20E%3E%3E` pointing to `std/result/enum.Result.html`
std/result/index.html:333: broken link fragment `#impl-Sum%3CResult%3CU%2C%20E%3E%3E` pointing to `std/result/enum.Result.html`
alloc/option/index.html:274: broken link fragment `#impl-FromIterator%3COption%3CA%3E%3E` pointing to `alloc/option/enum.Option.html`
alloc/option/index.html:285: broken link fragment `#impl-Product%3COption%3CU%3E%3E` pointing to `alloc/option/enum.Option.html`
alloc/option/index.html:286: broken link fragment `#impl-Sum%3COption%3CU%3E%3E` pointing to `alloc/option/enum.Option.html`
alloc/result/index.html:321: broken link fragment `#impl-FromIterator%3CResult%3CA%2C%20E%3E%3E` pointing to `alloc/result/enum.Result.html`
alloc/result/index.html:332: broken link fragment `#impl-Product%3CResult%3CU%2C%20E%3E%3E` pointing to `alloc/result/enum.Result.html`
alloc/result/index.html:333: broken link fragment `#impl-Sum%3CResult%3CU%2C%20E%3E%3E` pointing to `alloc/result/enum.Result.html`
checked links in: 5.7s
number of HTML files scanned: 33005
number of HTML redirects found: 10114
number of links checked: 2495078
number of links ignored due to external: 118674
number of links ignored due to exceptions: 19
number of intra doc links ignored: 25
errors found: 12
found some broken links
Build completed unsuccessfully in 0:22:26

[WaffleLapkin]

CI is green (also filled in tracking issue)

[m-ou-se]

I really don't think we should be using #[rustc_has_incoherent_inherent_impls].

There's a good reason we don't normally support incoherent impls. It makes maintenance hard, and can easily result in very surprising behavior. For example, no_std code could suddenly compile differently when some other crate in the dependency tree pulls in std. (We already have this issue with f32::sin(), which is something we should solve by moving that method to core.)

Unless we have a plan towards stabilizing something that allows every crate to do this, we should not be merging new incoherent impls into std. Ideally, std and alloc behave as much as possible like regular crates.

[klensy]

Current title and description says about Option, while this PR actually affects Result too.

[WaffleLapkin]

I don't think that this is a good idea anymore, @m-ou-se's comment summarizes the problems quite well. On top of that, 1) it can be implemented as a crate (via a trait) 2) these methods are not that commonly needed (my assumption, isn't backed by any data).

Thus, I'm closing this.