Skip to content

Add an SendStr type #9192

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 2 commits into from
Closed

Add an SendStr type #9192

wants to merge 2 commits into from

Conversation

Kimundi
Copy link
Member

@Kimundi Kimundi commented Sep 14, 2013

A SendStr is a string that can hold either a ~str or a &'static str.
This can be useful as an optimization when an allocation is sometimes needed but the common case is statically known.

Possible use cases include Maps with both static and owned keys, or propagating error messages across task boundaries.

SendStr implements most basic traits in a way that hides the fact that it is an enum; in particular things like order and equality are only determined by the content of the wrapped strings.

This basically reimplements #7599 and has a use case for replacing an similar type in std::rt::logging ( Added in #9180).


impl Ord for SendStr {
#[inline]
fn lt(&self, other: &SendStr) -> bool { self.cmp(other) == Less }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a particular reason that only this impl doesn't call as_slice and use the &str method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, I more or less just copied the existing str impls. I can change it if you want.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being internally consistent would be good, I guess, so can you convert this to self.as_slice().lt(&other.as_slice())?

A SendStr is a string that can hold either a ~str or a &'static str.
This can be useful as an optimization when an allocation is sometimes needed but the common case is statically known.

Possible use cases include Maps with both static and owned keys, or propagating error messages across task boundaries.

SendStr implements most basic traits in a way that hides the fact that it is an enum; in particular things like order and equality are only determined by the content of the wrapped strings.

Replaced std::rt:logging::SendableString with SendStr
Added tests for using an SendStr as key in Hash- and Treemaps
Split up test function a bit
bors added a commit that referenced this pull request Sep 16, 2013
A SendStr is a string that can hold either a ~str or a &'static str.
This can be useful as an optimization when an allocation is sometimes needed but the common case is statically known.

Possible use cases include Maps with both static and owned keys, or propagating error messages across task boundaries.

SendStr implements most basic traits in a way that hides the fact that it is an enum; in particular things like order and equality are only determined by the content of the wrapped strings.

This basically reimplements #7599 and has a use case for replacing an similar type in `std::rt::logging` ( Added in #9180).
@bors bors closed this Sep 16, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Oct 6, 2022
[`needless_return`] Recursively remove unneeded semicolons

fix rust-lang#8336,
fix rust-lang#8156,
fix rust-lang/rust-clippy#7358,
fix rust-lang#9192,
fix rust-lang/rust-clippy#9503

changelog: [`needless_return`] Recursively remove unneeded semicolons

For now the suggestion about removing the semicolons are hidden because they would be very noisy and should be obvious if the user wants to apply the lint manually instead of using `--fix`. This could be an issue for beginner, but haven't found better way to display it.
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.

3 participants