-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add trait std::vec::IntoVec #13737
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 trait std::vec::IntoVec #13737
Conversation
std::vec::IntoVec provides the .into_vec() method, similar to std::slice::CloneableVector. It does not provide .to_vec(), because that requires Clone, and can instead just be provided on individual types separately.
@@ -322,6 +318,13 @@ impl GenericPath for Path { | |||
} | |||
} | |||
|
|||
impl IntoVec<u8> for Path { | |||
#[inline] | |||
fn into_vec(self) -> Vec<u8> { |
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.
I marked this #[inline]
to match WindowsPath
. It seems like something that should be trivially inlined anyway, I'm not sure why it wasn't marked as such before.
We've generally been trying to avoid one-off traits, and this does seem a bit like a one-off trait. I think this should be discussed to make sure this is the direction we want to go in. |
Discussion is fine. The intent of this trait is to be used where current code uses fn foo<V: CloneableVector<u8>>(v: V) {
let v = v.into_owned();
// do stuff with v
} In order to convert this over to fn foo<V: IntoVec<u8>>(v: V) {
let v = v.into_vec();
// do stuff with v
}
It's worth noting that |
@alexcrichton Do you have anything you want to discuss about this pull? Nobody has chimed in so far with any objections beyond your one point about one-off traits. |
I don't have much to add over that this still seems like a one-off trait that doesn't need to go in at this time. |
What if I add |
Perhaps we can wait for the dust to settle on |
Ok. I'm going to close it out for now for bors's sake, and I'll revisit later. |
…uirement configurable (rust-lang#13737) Fixes rust-lang#11846. This PR has three commits: - The first commit adds an `initializer-suggestions` configuration to control suggestion applicability when initializers are present. The following are the options: - "none": do not suggest - "maybe-incorrect": suggest, but do not apply suggestions with `--fix` - "machine-applicable": suggest and apply suggestions with `--fix` - The second commit fixes suggestions to handle field attributes (problem [noticed by @samueltardieu](rust-lang/rust-clippy#13737 (comment))). - The third commit adds `initializer-suggestions = "machine-applicable"` to Clippy's `clippy.toml` and applies the suggestions. (Nothing seems to break.) --- changelog: make `inconsistent_struct_constructor` "all fields are shorthand" requirement configurable
… deprecated configurations (rust-lang#14280) This PR does two things: - It renames `inconsistent_struct_constructor`'s configuration from `lint-inconsistent-struct-field-initializers` to `check-inconsistent-struct-field-initializers`. (I should have suggested `check-...` in [rust-lang#13737](rust-lang/rust-clippy#13737 (comment)).) - It causes Clippy to no longer suggest deprecated configurations. (Previously, Clippy would suggest `cyclomatic-complexity-threshold`, for example.) r? @y21 changelog: Rename `lint-inconsistent-struct-field-initializers` to `check-inconsistent-struct-field-initializers` changelog: No longer suggest deprecated configurations
std::vec::IntoVec provides the .into_vec() method, similar to
std::slice::CloneableVector. It does not provide .to_vec(), because that
requires Clone, and can instead just be provided on individual types
separately.