Skip to content

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

Closed
wants to merge 1 commit into from
Closed

Conversation

lilyball
Copy link
Contributor

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.

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> {
Copy link
Contributor Author

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.

@alexcrichton
Copy link
Member

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.

@lilyball
Copy link
Contributor Author

Discussion is fine.

The intent of this trait is to be used where current code uses ClonaeableVector. E.g. I have a function

fn foo<V: CloneableVector<u8>>(v: V) {
    let v = v.into_owned();
    // do stuff with v
}

In order to convert this over to Vec<u8> instead of ~[u8], I need a way to convert both &[T] and ~[T] into a Vec<T>, which is what IntoVec<T> provides. So the equivalent function is

fn foo<V: IntoVec<u8>>(v: V) {
    let v = v.into_vec();
    // do stuff with v
}

IntoVec<T> is missing to_vec() (the equivalent to CloneableVector<T>::to_owned()) because that method requires Clone, and into_vec() should be usable on ~[T] and Vec<T> without T: Clone (the impl for &[T] still requires Clone, of course). Also I don't think a .to_vec() trait method is particularly useful.

It's worth noting that std::str::Str contains to_strbuf() and into_strbuf() methods.

@lilyball
Copy link
Contributor Author

lilyball commented May 6, 2014

@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.

@alexcrichton
Copy link
Member

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.

@lilyball
Copy link
Contributor Author

lilyball commented May 6, 2014

What if I add .to_vec()/.into_vec() into slice::CloneableVector instead? I didn't do that initially because I thought it was unnecessary to require Clone for .into_vec().

@alexcrichton
Copy link
Member

Perhaps we can wait for the dust to settle on Vec<T> and ~[T] before reconsidering this patch?

@lilyball
Copy link
Contributor Author

lilyball commented May 7, 2014

Ok. I'm going to close it out for now for bors's sake, and I'll revisit later.

@lilyball lilyball closed this May 7, 2014
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jan 9, 2025
…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
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 3, 2025
… 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants