-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add Option::owned
#98061
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Option::owned
#98061
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
(rust-highfive has picked a reviewer for you, use r? to override) |
@rustbot label +T-libs-api -T-libs |
This comment has been minimized.
This comment has been minimized.
bb8bfb4
to
1ca1c0b
Compare
It should probably add same methods to |
@RReverser Good catch! I'll add |
I like the concept of this, but as a nit on the name, I think this should be |
That wouldn't be possible - let a: &Option<i32> = &Some(1);
let b: Option<i32> = a.to_owned(); |
30a4691
to
753e947
Compare
What about let x = Some(String::new());
let y: Option<&str> = x.borrowed(); |
@camsteffen your snippet can use |
Yeah I just realized that. Probably not many such use cases. |
Could an implementation for Edit: On second thoughts, that might not be possible given that this would need to be an inherent method in |
@zesterer we already need magic ( Still, I don't think implementation for |
☔ The latest upstream changes (presumably #102097) made this pull request unmergeable. Please resolve the merge conflicts. |
753e947
to
2a6f61c
Compare
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
This comment has been minimized.
This comment has been minimized.
/// to convert borrowed types to their owned variants. For example `Option<&[T]>` to | ||
/// `Option<Vec<T>>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// 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>`. |
@bors r+ |
…triplett Add `Option::owned` This PR adds the following public library APIs: ```rust impl<T: ?Sized> Option<&T> { pub const fn owned(self) -> Option<T::Owned> where T: ~const ToOwned; } impl<T: ?Sized> Option<&mut T> { pub fn owned(self) -> Option<T::Owned> where T: ~const 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 :')
@bors r- CI is not green
|
This comment has been minimized.
This comment has been minimized.
17d54aa
to
ac2709c
Compare
CI is green (also filled in tracking issue) |
I really don't think we should be using 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 Unless we have a plan towards stabilizing something that allows every crate to do this, we should not be merging new incoherent impls into |
Current title and description says about |
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. |
This PR adds the following public library APIs:
Option::owned
is similar toOption::cloned
andOption::copied
, but uses theToOwned
trait.I thought that would be easier, but since
ToOwned
is defined in the alloc crate this becomes incoherent :')