Skip to content

Feature request: Automatically convert String to &str when required. #17300

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
sandeep-datta opened this issue Sep 16, 2014 · 3 comments
Closed

Comments

@sandeep-datta
Copy link
Contributor

Please consider automatically converting Strings to string slices when a string is passed into a string slice context. Please pardon my total lack of experience with rust but I think this shouldn't introduce any bugs in the program since a string slice is a more restricted type than a String. Any thoughts?

Example:

fn takes_slice(slice: &str) {
    println!("Got: {}", slice);
}

fn main() {
    let s = "Hello".to_string();
    takes_slice(s);
}

instead of ...

fn main() {
    let s = "Hello".to_string();
    takes_slice(s.as_slice());
}

May be we can provide a conversion operator like C++ does?

@alexcrichton
Copy link
Member

Changes such as this would require an RFC, and you may be interested in rust-lang/rfcs#241 which would enable use cases almost like this.

@anshin
Copy link

anshin commented Sep 16, 2014

You may also be interested in rust-lang/rfcs#198.

@sandeep-datta
Copy link
Contributor Author

Thanks guys. I am new here, will browse through the RFCs.

lnicola pushed a commit to lnicola/rust that referenced this issue Jun 2, 2024
fix diagnostics clearing when flychecks run per-workspace

This might be causing rust-lang#17300 or it's a different bug with the same functionality.

I wonder if the decision to clear diagnostics should stay in the main loop or maybe the flycheck itself should track it and tell the mainloop?

I have used a hash map but we could just as well use a vector since the IDs are `usizes` in some given range starting at 0. It would be probably faster but this just felt a bit cleaner and it allows us to change the ID to newtype later and we can just use a hasher that returns the underlying integer.
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

No branches or pull requests

3 participants