Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions text/0000-slice-string-symmetry.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
- Feature Name: `slice_string_symmetry`
- Start Date: 2015-06-06
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

Add some methods that already exist on slices to strings and vice versa.
Specifically, the following methods should be added:

- `str::chunks`
- `str::windows`
- `str::into_string`
- `String::into_boxed_slice`
- `<[T]>::subslice_offset`

# Motivation

Conceptually, strings and slices are similar types. Many methods are already
shared between the two types due to their similarity. However, not all methods
are shared between the types, even though many could be. This is a little
unexpected and inconsistent. Because of that, this RFC proposes to remedy this
by adding a few methods to both strings and slices to even out these two types’
available methods.

# Detailed design

Add the following methods to `str`, presumably as inherent methods:

- `chunks(&self, n: usize) -> Chunks`: Returns an iterator that yields the
*characters* (not bytes) of the string in groups of `n` at a time. Iterator
Copy link
Contributor

Choose a reason for hiding this comment

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

“Character” is kinda ambiguous. (Unicode has four different definitions.) Maybe use chars instead?

element type: `&str`.

- `windows(&self, n: usize) -> Windows`: Returns an iterator over all contiguous
windows of character length `n`. Iterator element type: `&str`.

- `into_string(self: Box<str>) -> String`: Returns `self` as a `String`. This is
Copy link
Member

Choose a reason for hiding this comment

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

equivalent to `[T]`’s `into_vec`.

`split_at(&self, mid: usize) -> (&str, &str)` would also be on this list, but
there is [an existing RFC](https://github.com/rust-lang/rfcs/pull/1123) for it.

Add the following method to `String` as an inherent method:

- `into_boxed_slice(self) -> Box<str>`: Returns `self` as a `Box<str>`,
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps this could be into_boxed_str? I think we tend to refer to string slices as str instead of slice.

Copy link
Member

Choose a reason for hiding this comment

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

Perhaps this could be an implementation of Into trait? I don’t see this being used enough to warrant a new method. I’d actually argue for deprecation of Vec::into_boxed_slice and implementation of Into trait too.

Copy link
Member

Choose a reason for hiding this comment

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

That's somewhat related to #1153, but relying solely on Into unfortunately isn't without downsides. For example if I have a String and I know that I want to go to a Box<str> using the .into() method would require a type annotation, where a method like this would not. Overall we've been thinking so far that specific conversions (e.g. like this) will have named methods so they can be called ergonomically, but there will also likely be an Into implementation to satisfy generic bounds as well. Now that being said, we haven't yet posted the RFC to clarify these conversion conventions.

reallocating to cut off any excess capacity if needed. This is required to
provide a safe means of creating `Box<str>`.

Add the following method to `[T]` (for all `T`), presumably as an inherent
method:

- `subslice_offset(&self, inner: &[T]) -> usize`: Returns the offset (in
elements) of an inner slice relative to an outer slice. Panics of `inner` is
not contained within `self`.
Copy link
Member

Choose a reason for hiding this comment

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

I would personally prefer to not add this method to slices just yet, I suspect it won't survive stabilization of strings.


# Drawbacks

- `str::subslice_offset` is already unstable, so creating a similar method on
`[T]` is perhaps not such a good idea.

# Alternatives

- Do a subset of the proposal. For example, the `Box<str>`-related methods could
be removed.

# Unresolved questions

None.