-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Add Option::owned
#98061
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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 :')