Skip to content
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 a StringRef and a VecRef #7599

Closed
wants to merge 2 commits into from
Closed

Add a StringRef and a VecRef #7599

wants to merge 2 commits into from

Conversation

Aatch
Copy link
Contributor

@Aatch Aatch commented Jul 5, 2013

Adds types for representing either a static string/vector or an owned string/vector.

The vector implements most convenience methods available to other vectors, and the rest can be accessed via the .as_slice() method.

I ran into some issues with the string implementation trying to implement StrSlice on it, since the borrow checker has difficulty relating the lifetimes. All the standard methods are still available via the .as_slice() method, as before.

Both implementations have methods for converting to an owned version, and both have a to_owned_consume that consumes the type and only does an allocation if necessary.

Closes #6874


PS: I'm not sure on the names, if anybody has any better suggestions, I'm happy to change them.

Aatch added 2 commits July 5, 2013 18:19
This adds a `VecRef` that can hold either a ~[T] or a &'static [T]
This is the string equivalent of VecRef. I had some trouble with
lifetimes trying to implement StrSlice, so I've left it for now,
iterating on strings isn't as common and the .as_slice() method
merely means you need to add an extra method call.
@graydon
Copy link
Contributor

graydon commented Jul 5, 2013

I'm a bit confused about use case. Borrowing a slice exists for just this case, no? Code that can work on both static and dynamic strings...

@thestinger
Copy link
Contributor

@graydon: It allows you to have sendable containers of mixed ~str and &'static str without copying the static slices.

@Kimundi
Copy link
Member

Kimundi commented Jul 5, 2013

Related, fail!() accepts both ~str and &'static str by having a trait implemented on both.

@graydon
Copy link
Contributor

graydon commented Jul 5, 2013

Sendable, ok. Fail doesn't seem relevant, it could equally work on a borrowed dynamic slice, no?

@graydon
Copy link
Contributor

graydon commented Jul 7, 2013

looks like a legitimate compilation failure

@brson
Copy link
Contributor

brson commented Jul 8, 2013

@graydon: eventually (I've always assumed) fail will want to propagate error messages, not just log them to the console. There are several use cases in #6874.

@brson
Copy link
Contributor

brson commented Jul 8, 2013

The StrRef name though is pretty misleading though. I don't have any better ideas just now.

@Kimundi
Copy link
Member

Kimundi commented Jul 8, 2013

Maybe SendStr?

@brson
Copy link
Contributor

brson commented Jul 22, 2013

I also don't have any use cases for the vector variant of this, so I'm not sure if we want it just to maintain parity with str.

@emberian
Copy link
Member

emberian commented Aug 8, 2013

@Aatch needs a rebase

@catamorphism
Copy link
Contributor

Closing for lack of activity -- @Aatch, feel free to rebase and reopen.

This was referenced Sep 14, 2013
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).
flip1995 pushed a commit to flip1995/rust that referenced this pull request Sep 8, 2021
…-again, r=llogiq

Updating issue templates again for rustbot

It turns out that our current issue template can sometimes trigger a rustbot error message, as can be seen in [rust-lang#7626](rust-lang/rust-clippy#7626). I originally tested this in rust-lang#7599, but it's apparently a bit inconsistent. This PR adds backticks to the commands, as correctly suggested by `@mikerite` in the comments. (Thank you!)

``@rustbot` label +S-blocked`

---

Now I also pushed a tiny link fix as well. 🙃

---

changelog: none
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.

Create a string type that represents either ~str or &'static str
9 participants